Myisam is preferred without transaction and little
update(delete)
Big than 4G datafile can user Myisam merge table.
InnoDB with auto_increment primary key is preferred.
Few storage process
Guess: 20m
records max per table , 500G
data max per tablespace , 256 tables per database (may problem)
Use prepared statement and batch
Optimize Your Queries For the Query Cache
// query cache does NOT work
$r = mysql_query("SELECT username FROM user WHERE signup_date >= CURDATE()");
// query cache works!
$today = date("Y-m-d");
$r = mysql_query("SELECT username FROM user WHERE signup_date >= '$today'");
EXPLAIN Your SELECT Queries
LIMIT 1 When Getting a Unique Row
Index and Use Same Column Types for Joins
Do Not ORDER BY RAND()
Avoid SELECT *
t is a good habit to always specify which
columns you need when you are doing your SELECT’s.
Use ENUM over VARCHAR
Use NOT NULL If You Can
Store IP Addresses as UNSIGNED INT (?)
Fixed-length (Static) Tables are Faster
Vertical Partitioning
Vertical Partitioning is the act of splitting your table
structure in a vertical manner for optimization reasons.
Example
1: You might have a users table that contains
home addresses, that do not get read often. You can choose to split your table
and store the address info on a separate table. This way your main users table
will shrink in size. As you know, smaller tables perform faster.
Example
2: You have a “last_login” field in your
table. It updates every time a user logs in to the website. But every update on
a table causes the query cache for that table to be flushed. You can put that
field into another table to keep updates to your users table to a minimum.
But you also need to make sure you don’t constantly need to
join these 2 tables after the partitioning or you might actually suffer
performance decline.
Split the Big DELETE or INSERT Queries
If you have some kind of maintenance script
that needs to delete large numbers of rows, just use the LIMIT clause to do it
in smaller batches to avoid this congestion.
Smaller Columns Are Faster
Use an Object Relational Mapper
f you do not need the time component, use
DATE instead of DATETIME.
Consider horizontally spitting many-columned tables if
they contain a lot of NULLs or rarely used columns.
Be an SQL programmer who thinks in sets, not procedural
programming paradigms
InnoDB can’t optimize SELECT COUNT(*) queries. Use counter
tables! That’s how to scale InnoDB.
Prefer MM with hive
refer :
http://blog.tuvinh.com/top-20-mysql-best-practices/