mysql 自动启动,和 best practice

/etc/init.d/mysql restart

http://drupalsh.cn/Linux-apache-mysql-autostart

    * 确保/etc/rc.d/init.d/mysqld 存在，用service mysqld start能够正常启动
    * 运行命令：chkconfig --add mysqld
    * 运行命令: chkconfig --level 345 mysqld on
    * 重启即可

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/