一、表结构优化

1、根据自己的业务选择合适的引擎。比如:

在以下两点情况下必须使用InnerDB:

  ①可靠性高或者必须要求事务处理

  ②表更新和查询相当的频繁,并且表锁定的机会比较大的情况下,指定InnerDB存储引擎。

MyISAM建议使用场景:

  ①不需要使用事务的表。

  ②插入和查询很频繁,但是修改不频繁的表,比如日志信息表。

2、表设计时尽量符合三范式:行不可分。列不可分,表不可分

3、适当的反三范式:

没有冗余的数据库未必是最好的数据库,有时为了提高运行效率,就必须降低范式标准,适当保留冗余数据

4、为经常搜索和排序的字段建立索引

尽量不要对数据库中某个含有大量重复的值的字段建立索引。对于一个ENUM类型的字段来说,出现大量重复值是很有可能的情况

5、在Join表的时候使用相同类型的例,并将其索引

如果你的应用程序有很多 JOIN 查询,你应该确认两个表中Join的字段是被建过索引的。这样,MySQL内部会启动为你优化Join的SQL语句的机制。而且,这些被用来Join的字段,应该是相同的类型的。

6、合理的选择数据类型

  ①尽量把每个字段都设置成NOT NULL:不要使用null,因为mysql对null字段索引优化不佳,增加计算难度,在保存和处理上也要做更多的工作

  ②如果知道字符串固定长度,那么就用char型,不要用varchar型

  ③能使用枚举型的就不要用varchar类型:ENUM 类型是非常快和紧凑的。在实际上,其保存的是 TINYINT,但其外表上显示为字符串。这样一来,用这个字段来做一些选项列表变得相当的完美。

7、当表的字段过多时,进行垂直分割;如果数据过多时,进行水平分割

8、当用户量非常大的时候,还可有考虑用主从复制,读写分离。读从库,写主库

 二、sql语句优化

1、开启慢查询,对慢sql使用explain或desc进行性能分析

EXPLAIN 的查询结果还会告诉你你的索引主键被如何利用的,你的数据表是如何被搜索和排序的……等等。

在my.cnf中开启慢日志:

long_query_time = 2
slow-query-log = on                                                                                                                  
slow-query-log-file = /data/mysql/slow-query.log
log-queries-not-using-indexes

查看是否开启:

show variables like '%slow_query%';
show global status like '%slow%';

下列命令可以查出访问次数最多的20个sql语句:

mysqldumpslow -s c -t 20 slow-query.log

2、避免 SELECT *

从数据库里读出越多的数据,那么查询就会变得越慢。并且,如果你的数据库服务器和WEB服务器是两台独立的服务器的话,这还会增加网络传输的负载。

3、 尽量不要使用rand(),now(),curdata()系统自带函数,Mysql不会进行查询缓存

大多数的MySQL服务器都开启了查询缓,当有很多相同的查询被执行了多次的时候,这些查询结果会被放到一个缓存中,这样,后续的相同的查询就不用操作表而直接访问缓存结果了。像 NOW() 和 RAND() 或是其它的诸如此类的SQL函数都不会开启查询缓存,因为这些函数的返回是会不定的易变的。所以,你所需要的就是用一个变量来代替MySQL的函数,从而开启缓存。

// 查询缓存不开启 
$r = mysql_query("SELECT username FROM user WHERE signup_date >= CURDATE()"); 
// 开启查询缓存 
$today = date("Y-m-d"); 
$r = mysql_query("SELECT username FROM user WHERE signup_date >= '$today'");

4、使用连接(JOIN)来代替子查询(Sub-Queries)

5、使用联合(UNION)来代替手动创建的临时表

6、不要在查询语句的WHERE条件里面使用函数,否则会导致索引不生效

7、in 和 not in 要慎用,否则会导致全表扫描,对于连续的数值,能用 between 就不要用 in 了

8、使用PHP的mysqli或者PDO预处理语句(Prepared Statements)

在安全方面,Prepared Statements很像存储过程,是一种运行在后台的SQL语句集合,我们可以从使用 prepared statements 获得很多好处,无论是性能问题还是安全问题。Prepared Statements 可以检查一些你绑定好的变量,这样可以保护你的程序不会受到“SQL注入式”攻击。

在性能方面,当一个相同的查询被使用多次的时候,可以给这些Prepared Statements定义一些参数,而MySQL只会解析一次

9、拆分大的 DELETE 或 INSERT 语句

如果需要在一个在线的网站上去执行一个大的 DELETE 或 INSERT 查询,你需要非常小心,要避免你的操作让你的整个网站停止响应。因为这两个操作是会锁表的,表一锁住了,别的操作都进不来了。

应该把其拆分,每次执行少量sql的操作。

while (true) { 
//每次只做1000条 
mysql_query("DELETE FROM logs WHERE log_date <= '2009-11-01' LIMIT 1000"); 
if (mysql_affected_rows() == 0) { 
// 没得可删了,退出! 
break; 
} 
// 每次都要休息一会儿 
usleep(50000); 
}

 三、其他优化

1、连接数优化

有时会遇见”MySQL: ERROR 1040: Too manyconnections”的情况,一种是访问量确实很高,MySQL服务器抗不住,这个时候就要考虑增加从服务器分散读压力,另外一种情况是MySQL配置文件中max_connections值过小。

查看最大连接上限:

show variables like 'max_connections';

查询服务器响应的最大连接数:

show global status like 'Max_used_connections';

 2、key_buffer_size:索引缓冲区大小的优化

key_buffer_size指定索引缓冲区的大小,它决定索引处理的速度,尤其是索引读的速度,通过key_read_requests和key_reads可以直到key_baffer_size设置是否合理。

查看key_buffer_size的值:

show variables like "key_buffer_size%";

查看key_read_requests和key_reads的值:

show global status like 'key_read%';

mysql 性能优化PROFILING_mysql

表示:一共有8个索引读取请求,有2个请求在内存中没有找到直接从硬盘中读取索引

key_buffer_size只对myisam表起作用,即使不使用myisam表,但是内部的临时磁盘表是myisam表,也要使用该值。

3、innodb_buffer_pool_size:索引缓冲区大小的优化

对于InnoDB表来说,innodb_buffer_pool_size的作用就相当于key_buffer_size对于MyISAM表的作用一样。InnoDB使用该参数指定大小的内存来缓冲数据和索引。对于单独的MySQL数据库服务器,最大可以把该值设置成物理内存的80%。

查看innodb_buffer_pool_size的值:

show variables like'innodb_buffer_pool_size';

 

 


 


=======================================

由于本人水平有限,文章在表述和代码方面如有不妥之处,欢迎批评指正。留下你的脚印,欢迎评论哦。你也可以关注我,一起学习哦!