MySql优化

最新推荐文章于 2025-05-20 10:09:32 发布

Leopard锋

最新推荐文章于 2025-05-20 10:09:32 发布

阅读量266

点赞数

分类专栏： mysql 文章标签： mysql

本文链接：https://blog.csdn.net/u014799292/article/details/90200534

版权

mysql 专栏收录该内容

2 篇文章

订阅专栏

一、Sql本身优化

1、避免使用 select * ，或当只要一行数据时使用 LIMIT 1

一、Sql本身优化

1、避免使用 select * ，或当只要一行数据时使用 LIMIT 1

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

当查询表的时候，已经知道结果只会有一条结果或只要需要有返回数据时，加上 LIMIT 1 可以增加性能。这样一样，MySQL数据库引擎会在找到一条数据后停止搜索，而不是继续往后查少下一条符合记录的数据。

2、避免嵌套子查询

原SQL查询关联表中name字段：

select (select name from testone_copy t2 where t1.id = t2.tId ) from testone t1

初始这样的写法没什么问题，但一旦遇到海量数据的时候，查询效率异常低下。改为关联查询如下：

select name from testone t1 inner join testone_copy t2 on t1.id = t2.tId

可自行测试，效率明显提升，关联查询除了 inner join 还有常用的 left join ，这里不用 left join 是因为

left join在任何场景下都不会比inner join的执行效率高因为left join除了需要所有inner join的结果集以外还需要左表的所有没有关联上的数据
left join除了要求关联字段有索引以外，最好将小表作为左表，因为检索的循环次数更少，前提是你的业务逻辑没问题，因为不同的写法逻辑是不一样的
inner join会自动选择合适的表作为基础表，也仍然要求有关联字段索引，并且最好是int型检索效率更高
left join(左联接) 返回包括左表中的所有记录和右表中联结字段相等的记录
inner join(等值连接) 只返回两个表中联结字段相等的行

3、避免使用不等于符号

常见的不等于有 not in、<>、!= 等，有些推荐 <>代替 != 是因为在某些版本中（如sql2000） != 会造成语法错误，但三者的使用都会造成无法使用索引。

4、union效率优于or、in

网上很多的声音都是说union all 快于 or、in，因为or、in会导致全表扫描。但实际情况要结合自己的语句，对应的查找字段有建立索引条件，查询关联条件要匹配实际业务条件，效率才高。

文章也借鉴：mysql 实战 or、in与union all 的查询效率

以下举个特别例子，建立简单的testone表，表中有50W数据，并建立有 val 和 bb 的组合索引和分开的单列索引

实际结果是，使用 or 没用到索引条件，union all 有用到索引条件，但union all 在联合查询时，进行了全表扫描，使得时间长于 or 的使用，所以实际应用要结合SQL和表数据本身来调整。

5、Null/Not Null的影响

很多表都包含可为NULL的列，即使应用程序并不需要保存NULL也是如此，这是因为可为NULL是列的默认属性（TIMESTAMP除外），然而通常情况下最好指定列为NOT NULL，除非真的需要存储NULL值。
如果查询中包含可为NULL的列，对MySQL来说更难优化，因为可为NULL的列使得索引统计和值比较更加复杂。可为NULL的列会使用更多的存储空间，在MySQL里也需要特殊的处理。当可为NULL的字段被索引时，每个索引记录需要一个额外的字节，在MyASIM里甚至还可能导致固定大小的索引（例如只有一个整数列的索引）变成可变大小的索引。
通常把可为NULL的列改为NOT NULL 带来的性能提升比较小，所以（调忧时）没有必要首先在现有schema中查找并修改这种情况，除非确定这会导致问题。但是，如果计划在列上建索引，就应该尽量避免设计为NULL的列。当然也有一些例外，例如值得一提的是，InnoDB使用单独的位（Bit）存储NULL值，所以对于稀疏数据（很多值为NULL，只有少数行是非NULL）有很好的空间效率。但这一点不适用于MyISAM。

---引用自《高性能MySQL－第三版》第四章 Schema与数据类型优化

在实际运用中，如果查询的字段设置为“允许空值”，is null是可以被索引使用，只是查询效率会降低很多，这一点可以在mysql官网查看8.2.1.13 IS NULL优化

6、注意范围查询边界值

无论是 >=、<= 或是 between and 的范围查询，都要注意边界值，以上述的50W数据表为例

在50W数据中，查询范围在【100,56560】的闭区间内，均使用到索引条件，下面把范围增加1查看下

可以看到查询改为全表扫描，没有使用到索引条件。

在使用范围查询时，系统查询优化时会有个范围值，超过后使用全表扫描。

二、索引优化和最左匹配原则

索引是对数据库表中一列或多列的值进行排序的一种结构，使用索引可快速访问数据库表中的特定信息。即：索引是数据结构

索引分类：

聚集索引：并不是一种单独的索引类型，而是一种数据存储方式，具体细节取决于不同的实现。innoDB的聚集索引是在同一个结构中保存B-Tree索引（从技术上来说是B+Tree索引）和数据行。每个表只能有一个聚集索引，因为目录只能按照一种方法进行排序。
非聚集索引：不是聚集索引，就是非聚集索引

索引种类：

普通索引：即一个索引只包含单个列，一个表可以有多个单列索引，仅加速查询
唯一索引：索引列的值必须是唯一，但允许有空值，(主键索引是一种特殊的唯一索引不允许空值)
联合索引：即一个索引包含多个列
全文索引：FULLTEXT即为全文索引，目前只有MyISAM引擎支持。（这里使用的是InnoDB，需要的可以自行搜索）。

   索引文件位置：show global variables like "%datadir%";（datadir是数据库的数据库）
   查看索引：show index from table_name
   创建索引：create (unique) index index_name on table_name(columnname)
alter table 表名 add (unique) index index_name (columnname)
   删除索引：drop index index_name on table_name

建立索引也要考虑列的离散型：离散型越高，选择性越好。计算方式：count（distinct col ） : count (col)

如使用 select count(aa), count(bb) from 表名，谁的值大，说明这一些列的离散度更高！离散度大的列放到联合索引的前面。

最左匹配原则：对索引关键字进行计算（对比），一定是从左向右依次进行，且不可跳过。

口诀：

全值匹配我最爱，最左前缀要遵守；

带头大哥不能死，中间兄弟不能断；

索引列上无计算，范围之后全失效；

like百分加右边，覆盖索引不写星*；

不等空值还有or，索引失效要少用；

字符串里有引号，SQL高级也不难。

1、尽量使用全值匹配

2、like查询

搜索索引关键字时，是从左往右依次进行的，只要左边数值确定，可依次进行

Where 条件中 like abc% ：可以使用到索引，注意的是，如果查询范围太广，依旧会然索引失效

like %abc 和 like %abc% 两者无法使用索引。但可以使用覆盖索引（下面有介绍）来使索引生效。

3、不操作索引列

不在索引列上做任何操作（计算、函数、自动or手动类型转换），会导致索引失效而转向全表扫描。即使满足最左前缀原则，但where条件中使用了函数后，索引失效

4、多使用覆盖索引

覆盖索引：如果索引包含所有满足查询需要的数据的索引成为覆盖索引(Covering Index)，也就是平时所说的不需要回表操作。（只访问索引的查询（索引列和查询列一致）），减少select *

判断标准
使用explain，可以通过输出的extra列来判断，对于一个索引覆盖查询，显示为using index,MySQL查询优化器在执行查询前会决定是否有索引覆盖查询

具体详情可参见：mysql高效索引之覆盖索引

5、字符串不加引号索引失效

如：将某个保存数字的字段更改为 char类型保存，并对该字段建立索引，在where条件搜索时，不添加引号可以依旧可以查找出数据，但索引无效。

6、范围条件放最后

存储引擎不能使用索引中范围条件后边的列。

举例说明：以上述表创建一个 val 和 bb 的联合索引。

“bb”位于索引最后，使用范围，通过key_len计算（计算方式这里展示不介绍）可以看出充分使用到了索引

接下来把条件调换下：

可以看到，虽然有用到索引，但不能充分利用。

对于索引的使用效率，可了解下explain执行计划的使用：MySQL 性能优化神器 Explain 使用分析

最左原则失效？

Mysql使用版本是5.7，在where查询语句后面，查询字段不是按索引创建字段的顺序查询，可依然有效。不是最左原则失效，是系统查询时做了优化，自行排列成最优查询。

顺序为：val,bb.code

查询条件没按最左原则处理，但系统自动优化排序后，符合“带头大哥不能死，中间兄弟不能断”，因此依旧充分使用到索引。

key_len 的计算（.utf_8 需＋3个长度，允许 null 值 +1个长度），参考：mysql 各数据类型的大小及长度

以上述为例，先贴出来下表结构：

CREATE TABLE `testone` (
  `id` int(11) NOT NULL DEFAULT '0',
  `val` int(11) DEFAULT NULL,
  `bb` int(11) DEFAULT '2',
  `code` varchar(50) DEFAULT 'test',
  PRIMARY KEY (`id`),
  KEY `valindex` (`val`,`bb`,`code`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

valindex 的索引利用率 key_len = （4+1）+ （4+1）+（50*3+2+1）= 163

要验证是否可以充分利用索引，提高效率，可参见：Mysql中explain作用详解

三、反范式设计优化

先了解下原三大范式：

第一范式：所有字段都只有单一属性，单一属性的列是由基本数据类型构成，设计出来的表都是简单的二维表
第二范式：要求表中只具有一个主键，不能存在非主键列只对部分主键的依赖关系。（解决方案：建立中间表）
第三范式：指每一个非主属性既不部分依赖也不传递依于业务主键，减少冗余。（解决方案：建立外键表）

反范式设计优化：允许少量冗余，使用空间获取时间