On Thu, Nov 25, 2010 at 2:38 PM, Mike Cochrane <[email protected]> wrote: > 1. Using MyISAM rather than InnoDB > Using MyISAM without thinking about it is more of a problem. There are times > when MyISAM is very much the most appropriate option out of those two. An > example is when full text indexes are needed. > > 2. Using PHP’s mysql functions > Agreed, mysqli should be used of mysql. > > 3. Not sanitizing user input > 4. Not using UTF-8 > 5. Favoring PHP over SQL > Agreed. > > 6. Not optimizing your queries > "99% of PHP performance problems will be caused by the database" I'm not > sure where this number comes from but it certainly not the case in the code > I work with. Optimizing your queries is something that should dedicated time > to after profiling of the code has been done to ensure it is worth the > effort. Sometimes there are many simple optimizations to the PHP code and > server config that will give better gains. > > 7. Using the wrong data types > 8. Using * in SELECT queries > Basically agreed. > > 9. Under- or over-indexing > Indexes should be created where needed. Enable slow query logging and log > queries that don't use indexes and see where they're actually going to make > a difference. Once all your indexes in place ensure that mysql is configured > such that those indexes stay in memory so they give maximum gains, see 12. > > 10. Forgetting to back up > Very important! We do nightly database dumps that are stored in our office > (DB servers are not in our office) keeping every day for the last week, > every week for the last month and every month for the last three. Being in > the office we can easily import them on a development server and manually > recover rows when clients do silly things. > > 11. Bonus mistake: not considering other databases! > True, also consider patches/branches of mysql and alternative storage > engines and plugins for mysql eg MariaDB - http://mariadb.org/ > > 12. Running MySQL with default config files > I've seen this a number of times, you should performance tune mysql to suit > your usage patterns. The default config will get you up and running but > won't get you anywhere near the performance available. > > - Mike > > On 25/11/2010 14:17, Admin wrote: >> >> Saw this and wondered what the 'professionals' had to say on the >> matter... >> >> >> http://blogs.sitepoint.com/2010/11/19/mysql-mistakes-php-developers/ >> >> Please note: Flame me not - none of these are *my* words... but I >> thought a bit of considered debate would be worth the risk. ;) >> >> >> >> --- >> Karl >> > > -- > NZ PHP Users Group: http://groups.google.com/group/nzphpug > To post, send email to [email protected] > To unsubscribe, send email to > [email protected] >
Hi, > 10. Forgetting to back up > Very important! We do nightly database dumps that are stored in our office > (DB servers are not in our office) keeping every day for the last week, > every week for the last month and every month for the last three. Being in > the office we can easily import them on a development server and manually > recover rows when clients do silly things. > Totally recommended. We do 1 hourly here on server, 6 hourly off server. Also good if you need to know who broke what when. Kind Regards, Jochen -- NZ PHP Users Group: http://groups.google.com/group/nzphpug To post, send email to [email protected] To unsubscribe, send email to [email protected]
