Just a few things that pop into mind...
(a) I second one of the above posters - try to move more content into the "static" section. This should be just a basic design principle of the site. For example: is there content that doesn't refresh more often than each 5 minutes? If so, don't let a PHP page pull it out of MySQL; instead, write a stand-alone PHP or Perl script that accesses the database and pre-cooks an HTML page. I'm often surprised how many sites build dynamic content using a CMS (or ~like) approach while this is totally unnecessary and bad for performance too.
(b) On the database access layer: of course stored procedures and prepared SQL statements.
(c) In general, when e.g. validating user input, or remote IP addresses, or just about anything: Use whitelists, never blacklists - meaning: have a set of allowed inputs which are accepted, and all else is denied (instead of the other way 'round). Test extensively for e.g. Javascript injection in input fields.
(d) On PHP coding: Try to abstract all operations into layers / classes. It will save you tons of headaches later. Never "take a shortcut" in coding, by which I mean that you do the quick 'n' dirty thing because "this code will only be used on this page" or "this code will be here just for testing". Quick 'n' dirty code tends to boomerang back to you.
(e) During coding, prepare your regression tests, which are preferably automatically run every time you update the site. Regression tests can e.g. include a fancy PHP class and call its methods, and compare the outcome with what the test expects. Always have regression tests for the "good" outcome (no errors) AND for the error conditions that your class should be able to handle. Here too, never take the quick 'n' dirty approach by postponing the writing of tests until you have more time.
(f) Whichever technology you choose, follow the forums or mailing lists about that technology. There will be security-related posts or questions that may apply to your site.
(g) Strip data that you don't need. For example: Maybe your site stores your visitor's IP addresses so you can cave trolls. Good practice, but the address will probably be only valid for a week or so. Ergo.. delete IP addresses that are older than a week. In the unfortunate case of a database disclosure there will be simply less exposed data. In a similar vein, try not to store plain text data at all. If your site stores something like the answer to a secret question ("what is your pet's name"), then store a hashed value of the answer instead of the plaintext version. Again, in the case of exposure, there will be less data.
(h) Take a look at frameworks that protect from e.g. cross site request forgery. If you don't find anything useful, consider coding your own protection against CSRF (by having a hidden form field in each form with a random value, and by having the same value in the user's session. Upon submission of the form, the two values must match.
(i) Other than the above I'm sure that there is a ton of good advice.. It's a bit of a lengthy post but I hope that it provides you with a few valid pointers.
