本文提供了一系列MySQL性能优化的方法，包括配置mysqld自启动、选择合适的存储引擎如MyISAM和InnoDB、合理使用预编译语句及批量操作、查询优化以利用查询缓存、避免全表扫描以及垂直分区等策略。
/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/
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/
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
