mysql常见的优化需要注意的点

1.explain分析
explian引用
索引基数
show indexes from table_name;
主键索引具有最好的基数

测试时

不走缓存
SELECT SQL_NO_CACHE id from test_null;

2.更好的索引类型
索引列尽可能的为not null ,避免在可空的列索引上进行二次扫描
要尽量避免 NULL ,关于索引列为Null的是否走索引,见测试 索引列的值为null查询时走索引的情况
3.使用unique index
与常规索引比不需要进行索引范围扫描
4.使用primary key
主键是uniquekey的一种特殊形式 。在innodb中,一个uniquekey是一个聚集索引(即对磁盘上数据排列的索引),当数据按照主键的次序进行检索时会极大改进性能
5.索引太多是有害的
例如,如果possible_keys 列表中有超过3个的索引,mysql优化器有太多信息而无法确定最好使用哪个索引,也就意味着有些是低效或者无用的索引
6.索引列使用最小可能的数据类型
比如在一个varchar(100)甚至更大的列上建立索引,一种改进方法是建立一个额外的列,并在包含较大的varchar(100)列的md5值的额外varchar(32)列上创建索引。
更好的方法是使用bigint来存储md5值的数字表示,数字索引更加高效
CONV(N,from_base,to_base)

mysql> select conv(‘a‘,16,10);
+-----------------+
| conv(‘a‘,16,10) |
+-----------------+
| 10              |
+-----------------+
mysql> select conv(substr(md5(‘abc‘),1,16),16,10);
+-------------------------------------+
| conv(substr(md5(‘abc‘),1,16),16,10) |
+-------------------------------------+
| 10376663631224000432                |
+-------------------------------------+

7.建立索引时
如果使用到多个列,定义多列索引
哪列的唯一性更高(基数大 show indexes from table_name),哪列优先放在多列索引的前面
覆盖索引是理性的索引
覆盖索引包括所有需要的列,但是不需要读取单独的数据页,实际意味着不需要读取数据存储,只利用索引数据就可以检索到实际想要的查询的数据
在myisam表里,意味着只要读入索引就可以得到问题的记录,在innodb中 索引和数据是位于同一个文件中的,但仍然会高效些,因为只需要读入索引
优化部分索引的性能
与其在长字符的列上定义索引,还不如只在左边的一小部分上建立索引

8.一些常见的不使用索引的情况
开始字符是通配符是,或者 在索引列上使用标量函数
like "%123",upper()
9.覆盖索引的左前缀原则

10.更详细的分析
set profiling=1;
select * from table;
show profile;
show profile source ;

mysql> select * from test_null where mark like ‘aaa9999%‘;
+------+---------+
| id   | mark    |
+------+---------+
| 9999 | aaa9999 |
+------+---------+
1 row in set

mysql> show profile;
+----------------------+----------+
| Status               | Duration |
+----------------------+----------+
| starting             | 5.5E-5   |
| checking permissions | 1.1E-5   |
| Opening tables       | 2E-5     |
| init                 | 2.4E-5   |
| System lock          | 7E-6     |
| optimizing           | 8E-6     |
| statistics           | 1.4E-5   |
| preparing            | 7E-6     |
| executing            | 2E-6     |
| Sending data         | 0.006271 |
| end                  | 5.7E-5   |
| query end            | 3.6E-5   |
| closing tables       | 5.1E-5   |
| freeing items        | 0.000348 |
| cleaning up          | 0.00011  |
+----------------------+----------+
mysql> show profile source;
+----------------------+----------+-----------------------+----------------------+-------------+
| Status               | Duration | Source_function       | Source_file          | Source_line |
+----------------------+----------+-----------------------+----------------------+-------------+
| starting             | 5.5E-5   | NULL                  | NULL                 | NULL        |
| checking permissions | 1.1E-5   | check_access          | sql_authorization.cc |         835 |
| Opening tables       | 2E-5     | open_tables           | sql_base.cc          |        5648 |
| init                 | 2.4E-5   | handle_query          | sql_select.cc        |         121 |
| System lock          | 7E-6     | mysql_lock_tables     | lock.cc              |         321 |
| optimizing           | 8E-6     | JOIN::optimize        | sql_optimizer.cc     |         151 |
| statistics           | 1.4E-5   | JOIN::optimize        | sql_optimizer.cc     |         367 |
| preparing            | 7E-6     | JOIN::optimize        | sql_optimizer.cc     |         475 |
| executing            | 2E-6     | JOIN::exec            | sql_executor.cc      |         119 |
| Sending data         | 0.006271 | JOIN::exec            | sql_executor.cc      |         195 |
| end                  | 5.7E-5   | handle_query          | sql_select.cc        |         199 |
| query end            | 3.6E-5   | mysql_execute_command | sql_parse.cc         |        4952 |
| closing tables       | 5.1E-5   | mysql_execute_command | sql_parse.cc         |        5004 |
| freeing items        | 0.000348 | mysql_parse           | sql_parse.cc         |        5578 |
| cleaning up          | 0.00011  | dispatch_command      | sql_parse.cc         |        1864 |
+----------------------+----------+-----------------------+----------------------+-------------+

优化update
换成select使用explain

优化delete

mysql> select * from parent;
+----+------+
| id | name |
+----+------+
|  1 | pa   |
|  2 | pb   |
|  3 | pc   |
|  4 | pd   |
+----+------+
4 rows in set

mysql> select * from child;
+-----------+----------+
| parent_id | child_id |
+-----------+----------+
|         1 |        1 |
|         2 |        2 |
|         3 |        3 |
|         1 |        4 |
|         1 |        5 |
|         2 |        6 |
|         0 |        7 |
|         5 |        8 |
|         6 |        9 |
|         5 |       10 |
+-----------+----------+

删除child中parent_id不在parent表的记录
一般的写法是
delete from child where parent_id not in(select id from parent);
更加高效的是使用连接查询
通过以下来验证

set profiling=1;
select * from child where parent_id not in(select id from parent);

select child.* from child left join parent on child.parent_id=parent.id where parent.id is null;

select query_id,count(*) as ‘#ops‘ ,sum(duration) from information_schema.profiling group by query_id;
select * from information_schema.profiling ;

演示结果
mysql> set profiling=1;
Query OK, 0 rows affected

mysql> select * from child where parent_id not in(select id from parent);
+-----------+----------+
| parent_id | child_id |
+-----------+----------+
|         0 |        7 |
|         5 |        8 |
|         6 |        9 |
|         5 |       10 |
+-----------+----------+
4 rows in set

mysql> select child.* from child left join parent on child.parent_id=parent.id where parent.id is null;
+-----------+----------+
| parent_id | child_id |
+-----------+----------+
|         0 |        7 |
|         5 |        8 |
|         6 |        9 |
|         5 |       10 |
+-----------+----------+
4 rows in set

mysql> select query_id,count(*) as ‘#ops‘ ,sum(duration) from information_schema.profiling group by query_id;
+----------+------+---------------+
| query_id | #ops | sum(duration) |
+----------+------+---------------+
|        1 |   23 | 0.000749      |
|        2 |   16 | 0.000388      |
+----------+------+---------------+

优化器显示第二个用了更少的操作
优化Insert,同一表的多条类似的多个insert改写成1条减少数据库的网络往返
例外一个好处是mysql只需为insert语句产生一次执行计划,可以在多个值上利用同一个执行计划
当批量插入时,如果单个插入失败,多个value子句说明的记录都无法插入成功

优化insert ...on duplicate key update
replace在内部是使用delete和insert来实现的,因而其效率并不高
使用insert ...on duplicate key update
如果存在同样主键值的记录,而其它列与现在存指定的记录有所不同,就更新该记录,如果记录不存在就插入该记录,如果记录存在而且没有任何值发生改变
就不做任何操作,优于replace

mysql> desc a;
+-------+----------+------+-----+---------+----------------+
| Field | Type     | Null | Key | Default | Extra          |
+-------+----------+------+-----+---------+----------------+
| id    | int(11)  | NO   | PRI | NULL    | auto_increment |
| sid   | int(11)  | YES  |     | NULL    |                |
| type  | char(10) | NO   |     | NULL    |                |
+-------+----------+------+-----+---------+----------------+
mysql> select * from a;
+----+-----+------+
| id | sid | type |
+----+-----+------+
|  1 |  11 | aa   |
|  2 |   1 | b    |
|  3 |   2 | c    |
|  4 |   3 | d    |
+----+-----+------+
mysql> insert into a(`id`,`type`) values(1,‘a1‘);
1062 - Duplicate entry ‘1‘ for key ‘PRIMARY‘
mysql> insert into a(`id`,`type`) values(1,‘a1‘) on duplicate key update type=‘a1‘;
Query OK, 2 rows affected
注意改变的是2行
mysql> insert into a(`id`,`type`) values(5,‘a5‘) on duplicate key update type=‘a5‘;
Query OK, 1 row affected
mysql> select * from a;
+----+------+------+
| id | sid  | type |
+----+------+------+
|  1 |   11 | a1   |
|  2 |    1 | b    |
|  3 |    2 | c    |
|  4 |    3 | d    |
|  5 | NULL | a5   |
+----+------+------+

待续...

原文地址:https://www.cnblogs.com/HKUI/p/8546859.html

时间: 2024-08-30 16:36:50

mysql常见的优化需要注意的点的相关文章

mysql常见的优化方法

1.选取适当的字段属性.例如,在定义邮政编码这个字段时,如果将其设置为CHAR(255),显然给数据库增加了不必要的空间,甚至使用VARCHAR这种类型也是多余的,因为CHAR(6)就可以很好的完成任务了.或者使用MEDIUMINT来定义整型字段. 2.应该尽量把字段设置为NOTNULL. 3.使用连接(JOIN)来代替子查询 4.事务处理 5.锁定表 6.使用外键 7.使用索引 该对哪些字段建立索引呢? 一般说来,索引应建立在那些将用于JOIN,WHERE判断和ORDERBY排序的字段上.尽量

MySQL常见注意事项及优化

MySQL常见注意事项 模糊查询 like 默认是对name字段建立了索引 注意:在使用模糊查询的时候,当% 在第一个字母的位置的时候,这个时候索引是无法被使用的.但是% 在其他的位置的时候,索引是可以被使用的. ? # select * from tableName where name like "%zhangsan"; ?可以使用到索引啊? 不可以. 分析:因为是不确定查询,在表中任何一行记录都有可能满足查询条件. ? #select * from tableName where

MYSQL常见的可优化点

MYSQL常见的可优化点 SQL常见的可优化点 2014年6月8日 DBA 发表回复 # #################################################### 索引相关# ###################################################1. 查询(或更新,删除,可以转换为查询)没有用到索引这是最基础的步骤,需要对sql执行explain查看执行计划中是否用到了索引,需要重点关注type=ALL, key=NULL的字段.

Mysql数据库性能优化(一)

参考 http://www.jb51.net/article/82254.htm 今天,数据库的操作越来越成为整个应用的性能瓶颈了,这点对于Web应用尤其明显.关于数据库的性能,这并不只是DBA才需要担心的事,而这更是我们程序员需要去关注的事情.当我们去设计数据库表结构,对操作数据库时(尤其是查表时的SQL语句),我们都需要注意数据操作的性能.这里,我们不会讲过多的SQL语句的优化,而只是针对MySQL这一Web应用最多的数据库. mysql的性能优化无法一蹴而就,必须一步一步慢慢来,从各个方面

架构设计:系统存储(9)——MySQL数据库性能优化(5)

=================================== (接上文<架构设计:系统存储(9)--MySQL数据库性能优化(5)>) 4-3-3-3.避免死锁的建议 上一篇文章我们主要介绍了MySQL数据库中锁的基本原理.工作过程和产生死锁的原因.通过上一篇文章的介绍,可以确定我们需要业务系统中尽可能避免死锁的出现.这里为各位读者介绍一些在InnoDB引擎使用过程中减少死锁的建议. 正确使用读操作语句 经过之前文章介绍,我们知道一般的快照读是不会给数据表任何锁的.那么这些快照读操作

MySQL索引与优化

1. 性能下降,sql执行时间长原因:查询语句没写好,索引失效,关联太多join,服务器参数设置不合理(JoinBuffer大小,SortBuffer大小,最大连接数)2. 使用join时应该小表驱动大表,小数据集驱动大数据集3. 索引:索引是帮助MySQL高效获取数据的一种数据结构,即索引的本质是数据结构.除了数据本身之外,MySQL数据库还维护着一个满足特定查找算法的数据结构,这些数据结构以某种方式指向数据,这样就可以在这些数据结构的而基础上实现高效的数据查找算法,这种数据结构就是索引. 4

常见性能优化策略的总结

本文是一位美团老师把之前所做的各种性能优化的案例和方案加以提炼.总结,以文档的形式沉淀下来,并在内部进行分享.力求达到如下效果: 形成可实践.可借鉴.可参考的各种性能优化的方案以及选型考虑点,同时配合具体的真实案例,其他人遇到相似问题时,不用从零开始: 有助于开阔视野,除了性能优化之外,也能提供通用的常见思路以及方案选型的考虑点,帮助大家培养在方案选型时的意识.思维以及做各种权衡的能力: 常见性能优化策略分类: 代码 之所以把代码放到第一位,是因为这一点最容易引起技术人员的忽视.很多技术人员拿到

常见性能优化策略的总结(转)

add by zhj: 我个人感觉性能优化分析影响性能的因素有哪些,然后按影响力的大小进行排序,然后进行排序. 然后进一步分析每个因素为何会影响性能,把这些因素再找出来,再按影响力大小进行排序.基本上,经过 这两层的分析,基本就够用了.对这些因素思考解决办法. 1. 数据库层 我们的目标是减少IO访问,或者将IO访问进行负载均衡,分配到多台服务器,并行计算. 1.1 数据库的数据存储在硬盘,硬盘访问速度比内存慢太多,即IO多 1.2 数据量大导致扫描记录多,间接导致IO多 1.3 所有数据库访问

MySQL数据库的优化(下)MySQL数据库的高可用架构方案

MySQL数据库的优化(下)MySQL数据库的高可用架构方案 2011-03-09 08:53 抚琴煮酒 51CTO 字号:T | T 在上一篇MySQL数据库的优化中,我们跟随笔者学习了单机MySQL数据库的优化,今天我们继续跟随笔者学习MySQL优化的集群方案. AD:51CTO 网+首届APP创新评选大赛火热启动——超百万资源等你拿! [51CTO独家特稿]在上一篇MySQL数据库的优化中,我们跟随笔者学习了单机MySQL数据库的优化,今天我们继续跟随笔者学习MySQL优化的集群方案. M