of the Dutch Web Alliance Development in PHP, Python, Perl, C, Java. Lead developer of Saffire. Blog: http://adayinthelifeof.nl Email: [email protected] Twitter: @jaytaph
| Key | Default | Extra | +----------+--------------+------+-----+---------+-------+ | id | int(11) | NO | PRI | 0 | | | name | varchar(255) | NO | MUL | NULL | | | utf8name | varchar(255) | NO | MUL | NULL | | +----------+--------------+------+-----+---------+-------+ 3 rows in set (0.01 sec) 1: Know how to use explain
| Message | +-------+------ +--------------------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------+ | Note | 1003 | select `zend`.`varchartest`.`id` AS `id`,`zend`.`varchartest`.`name` AS `name`,`zend`.`varchartest`.`utf8name` AS `utf8name` from `zend`.`varchartest` where (`zend`.`varchartest`.`name` like 'joshua') | +-------+------ +--------------------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------+ 1: Know how to use explain
two fields. 4: Don’t select what you don’t need Much more data to be read from disk Much more data will be send over, thus slower (blobs/texts) Cannot use covering indices
triggers per table (insert, update, delete, before and after the mutation) 3rd party tools (phpmyadmin etc) can also use the database without loosing data consistency. Watch out with (phpmyadmin) table dumps!
tables. Not compatible with other DB’s. Slow (especially compared to Solr, Sphinx). No extra features (faceted search, spell checking etc). You want to move to Lucene/Solr/ElasticSearch
careful with %wildcards% MySQL cannot use indexing! Revert your data: search for ‘ln.cigolxon@%’ instead of ‘%@noxlogic.nl’. Use a better solution (solr, sphinx). You probably want it (no, really)
referring to that table. UPDATE pages SET hit_count = hit_count + 1; Thus: page table will NEVER be cached. 8: Shard your volatile and non-volatile data
changes never or infrequently) move to different tables UPDATE page_stats SET hit_count = hit_count + 1; Query cache is happy again Bulk update (hitcount += 100) 8: Shard your volatile and non-volatile data
MySQL Associate Oracle Certified Professional MySQL 5.0 Developer Oracle Certified Professional MySQL 5.0 Database Administrator Oracle Certified Expert, MySQL 5.1 Cluster Database Administrator “Old”, but still, get them all!
basic my.cnf settings. (3) Backup on table level. (4) Don’t use “SELECT *” when you only need 1 or 2 fields. (5) Use triggers and stored procedures. (6) Don’t use FULLTEXT searches. (7) Wildcard searches (%item%) are bad for performance. (8) Shard your volatile and non-volatile data. (9) Don’t use a large Primary Key for InnoDB tables. (10) Don’t “Select COUNT(*)” on InnoDB. (11) Don’t rely on the VARCHAR(). (12) UTF-8 is not the enemy, but it certainly isn’t your friend. (13) Know your cardinality & selectivity. (14) Non-deterministic functions do not go well with query caching. (15) Certify yourself as a DBA and/or DBE.