MySQL进阶知识
目录
存储引擎
MySQL的体系结构
存储引擎简介
存储引擎特点
InnoDB
逻辑存储结构
MyISAM
Memory
对比
存储引擎选择
索引
介绍
索引结构
B+Tree索引
Hash索引
索引分类
索引语法
SQL性能分析
SQL执行频率
慢查询日志
profile详情
explain执行计划
索引的使用
最左前缀法则
范围查询
索引列运算
字符串加引号
模糊查询
or连接的条件
数据分布影响
SQL提示
覆盖索引
前缀索引
索引设计原则
SQL优化
insert优化
主键优化
页分裂
页合并
主键设计原则
order by优化
group by优化
limit优化
count优化
count的使用
update优化
存储引擎
MySQL的体系结构
连接层：最上层是一些客户端和链接服务，主要完成一些类似于连接处理、授权认证、及相关的安全方案。服务器也会为安全接入的每个客户端验证它所具有的操作权限。
服务层：第二层架构主要完成大多数的核心服务功能，如SQL接口，并完成缓存的查询，SOL的分析和优化，部分内置函数的执行。所有跨存储引擎的功能也在这一层实现，如 过程、函数等。
引擎层：存储引擎真正的负责了MySQL中数据的存储和提取，服务器通过API和存储引擎进行通信。不同的存储引擎具有不同的功能，这样我们可以根据自己的需要，来选取合适的存储引擎。
存储层：主要是将数据存储在文件系统之上，并完成与存储引擎的交互。
存储引擎简介
存储引擎就是存储数据、建立索引、更新/查询数据等技术的实现方式。存储引警是基于表的，而不是基于库的，所以存储引警也可被称为表类型。
在创建表的时候我们可以指定存储引擎，如果不指定默认为INNODB引擎
create table 表明{
字段1, 字段类型,
……
}ENGINE = 引擎名;
如果想查看当前数据库支持哪些存储引擎，我们可以使用语句
show engines;
存储引擎特点
InnoDB
一种兼顾高可靠性与高性能的通用引擎，在Mysql5.5之后，InnoDB是MySQL的默认存储引擎。
特点是：
- DML操作遵循ACID模型，支持事务;
- 支持行级锁，提高并发访问性能；
- 支持外键约束，保证数据的完整性和正确性；
存储文件：
xxx.ibd：xxx代表的是表名，innoDB引擎的每张表都会对应这样一个表空间文件，存储该表的表结构(frm、sdi)、数据和索引。该文件可以在Windows目录下C:\ProgramData\MySQL\MySQL Server 8.0\Data下找到，每个文件夹对应的是一个数据库。
如果需要通过idb文件查看表结构，可以通过命令
ibd2sdi 表名.ibd
逻辑存储结构
磁盘操作的最小单元为page，每个page是16K。而每个Extent大小为1M。也就是说，一个Extent包含64个page
MyISAM
MyISAM是MySQL早期的默认存储引擎
特点：
- 不支持事务，不支持外键
- 支持表锁，不支持行锁
- 访问速度快
存储文件：
- xxx.sdi：存储表结构信息
- xxx.MYD：存储数据
- xxx.MYI：存储索引
Memory
Memory引擎的表数据是存储在内存当中的，只能将使用Memory引擎的表作为临时表或缓存使用
特点：
- 内存存放，访问速度快
- 采用hash索引
存储文件：
- xxx.sdi：存储表结构信息
对比
| 特点 |
InnoDB |
MyISAM |
Memory |
| 存储限制 |
64TB |
有 |
有 |
| 事务安全 |
支持 |
- |
- |
| 锁机制 |
行锁 |
表锁 |
表锁 |
| B+tree索引 |
支持 |
支持 |
支持 |
| Hash索引 |
- |
- |
支持 |
| 全文索引 |
5.6版本后支持 |
支持 |
- |
| 空间使用 |
高 |
低 |
N/A |
| 内存使用 |
高 |
低 |
中等 |
| 批量插入速度 |
低 |
高 |
高 |
| 支持外键 |
支持 |
- |
- |
InnoDB与MyISAM最大的区别在于，InnoDB支持事务，支持行锁，支持外键
存储引擎选择
InnoDB：是Mysql的默认存储擎，支持事务、外键。如果应用对事务的完整性有比较高的要求，在并发条件下要求数据的一致性，数据操作除了插入和查询之外，还包含很多的更新、删除操作，那么InnoDB存储引擎是比较合适的选择。
MyISAM：如果应用是以读操作和插入操作为主，只有很少的更新和删除操作，并且对事务的完整性、并发性要求不是很高，那么选择这个存储引擎是非常合适的。
MEMORY：将所有数据保存在内存中，访问速度快，通常用于临时表及缓存。MEMORY的缺陷就是对表的大小有限制，太大的表无法缓存在内存中，而且无法保障数据的安全性。
通常来讲，我们使用InnoDB就足够了，MyISAM引擎用来记录日志等丢失几条消息也无所谓的信息，MEMORY因为无法存储太多数据，用来做缓存就可以了。但是MyISAM与MEMORY都可以被其他非关系型数据库来替代，比如说Redis。
索引
介绍
索引是帮助MySQL高效获取数据的数据结构(有序)。在数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种方式引用(指向)数据， 这样就可以在这些数据结构上实现高级查找算法，这种数据结构就是索引。
比如说存在这样一张表，接下来我们要找到age为45的用户，在没有对age字段添加索引的清空下，是通过id进行全表扫描，一行一行对比age=45的数据。
如果对age字段建立索引，在插入时，数据库会维护索引信息，查找时从根节点开始查找，查询速度快。
优点：
- 提高数据库查询效率，减少数据库IO成本
- 通过索引列对数据进行排序，降低数据排序的成本，降低CPU消耗
缺点：
- 索引会占用存储空间
- 索引大大提高了查询效率，同时也降低了Insert、Update、Delete效率
索引结构
MySQL的索引是在存储引擎层实现的，不同的存储引擎有不同的结构，主要包含以下几种：
| 索引结构 |
描述 |
| B+Tree索引 |
最常见的索引，大部分引擎都支持 B+ 树索引 |
| Hash索引 |
底层数据结构是用哈希表实现的,只有精确匹配索引列的查询才有效不支持范围查询 |
| R-Tree（空间索引） |
空间索引是MvISAM引擎的一个特殊索引类型，主要用于地理空间数据类型，通常使用较少 |
| Full-text（空间索引） |
是一种通过建立倒排索引，快速匹配文档的方式。类似于Lucene,Solr,ES |
引擎对索引结构的支持情况
| 索引 |
InnoDB |
MyISAM |
Memory |
| B+Tree索引 |
支持 |
支持 |
支持 |
| Hash索引 |
不支持 |
不支持 |
支持 |
| R-Tree索引 |
不支持 |
支持 |
不支持 |
| Full-text |
5.6之后支持 |
支持 |
不支持 |
B+Tree索引
默认都是使用B+Tree索引，但是MySQL又对经典的B+Tree做了一个优化，增加了一个指向相邻叶子节点的链表指针，形成了带有顺序指针的B+Tree，提高区间访问的性能。
为什么选择B+Tree索引结构？
相对于二叉树，层级更少，搜索效率高。
对于B-Tree，无论是叶子节点还是非叶子节点都存储数据，这样会导致一页中的存储的键值减少，指针跟着减少，如果需要保存大量数据，B-Tree的高度会比B+Tree高导致性能降低。其次，对B+Tree优化后，形成一个双线链表，对于范围查询更具有优势。
Hash索引
哈希索引就是采用一定的hash算法，将键值换算成新的hash值，映射到对应的槽位上，然后存储在hash表中
hash索引的特点
- 只能用于对等比较（=、in），不支持范围查询（between，>,<等）
- 无法利用索引完成排序操作
- 查询效率高，通常只需要一次检索。
索引分类
| 分类 |
含义 |
特点 |
关键字 |
| 主键索引 |
针对于表中主键创建的索引 |
默认自动创建，只能有一个 |
PRIMARY |
| 唯一索引 |
避免同一个表中某数据列中的值重复 |
可以有多个 |
UNIQUE |
| 常规索引 |
快速定位特定数据 |
可以有多个 |
|
| 全文索引 |
全文索引查找的是文本中的关键词，而不是比较索引中的值 |
可以有多个 |
FULLTEXT |
在InnoDB中根据索引的存储形式又可以分为以下两种
| 分类 |
含义 |
特点 |
| 聚集索引 |
将数据存储与索引放到了一块，索引结构的叶子节点保存了行数据 |
必须有，而且只有一个 |
| 二级索引 |
将数据与索引分开存储，索引结构的叶子节点关联的是对应的主键 |
可以存在多个 |
聚集索引的选取规则：
- 如果存在主键，主键索引就是聚集索引。
- 如果不存在主键，将使用第一个唯一(UNIQUE)索引作为聚集索引。
- 如果表没有主键，或没有合适的唯一索引，则InnoDB会自动生成一个rowid作为隐藏的聚集索引。
当需要对name字段进行查询时，先通过二级索引查找到对应的name键值，然后获取对应的id值，然后拿着id值取聚集索引中查找行信息，该操作叫做回表查询
InnoDB的主键索引B+Tree高度为多少？
B+Tree的高度，取决于主键数据类型，首先我们知道，B+Tree的非叶子节点是存储的只有键值与InnoDB的指针，而一个区块只能存放16K的内容，转化为字节为16*1024个字节。
首先InnoDB的指针占用6个字节，假设主键数据类型是bigint，需要占用8个字节的大小，在高度为2的情况下，计算公式为：
n*8+(n+1)*6 = 16*1024
计算出n约等于1170。
如果一行数据大小为1k。那么在高度为2的情况下可以存储 1171*16 =18736 数据。
在高度为三的情况，可以存储1171*1171*16 = 21939856 条数据
索引语法
创建索引
CREATE [ UNIQUE|FULLTEXT] INDEX index_name ON table_name (index_col_name,…);字段可以同时选取多个，这被称为联合索引或组合索引（需要注意的是，创建索引时，字段名的顺序会影响查找的效率，这个我们后面）
查看索引
SHOW INDEX FROM table_name;删除索引
DROP INDEX index_name ON table_name;SQL性能分析
SQL执行频率
在对SQL进行优化的时候，我们需要知道该数据库主要是哪些语句执行次数多，将优化重心就放在执行次数多的语句当中，查询SQL执行次数语句如下
SHOW [GLOBAL|SESSION] STATUS LIKE 'Com_______';
慢查询日志
慢查询日志记录了所有执行时间超过指定参数（long_query_time，单位：秒，默认10秒）的所有SQL语句的日志。MySQL的慢查询日志默认关闭，需要在MySQL的配置文件（etc/my.cnf）中配置如下信息：
# 开启MySQL慢日志开关
slow_query_log = 1
# 设置慢日志的超时时间为2s
long_query_time = 2慢日志记录位置为/var/lib/mysql/localhost-slow.log
profile详情
show profiles 能够在做SQL优化时帮助我们了解时间都耗费到哪里去了。通过have profiling参数，能够看到当前MySQL是否支持profile操作:
SELECT @@have_profiling;默认profiling是关闭的，可以通过set语句在session/global级别开启profiling:
SET profiling = 1;当开启之后执行
# 会查看到每一条SQL的执行时间
show profiles;
# 查看指定query_id的SQL语句各个阶段的耗时情况
show profile for query query_id;
# 查看指定query_id的SQL语句CPU使用情况
show profile cpu for query query_id;
explain执行计划
EXPLAIN或者DESC命令可以获取MySQL如何执行SELECT语句的信息，包括在SELECT语句执行过程中如何连接和连接顺序。
语法：
# 在select语句前直接加EXPLAIN或是DESC
EXPLAIN SELECT 字段列表 FROM 表名 WHERE 条件;
字段解释
id
select查询的序列号，表示查询中执行select子句或是操作表的顺序，执行顺序从上到下（id相同，从上到下，id不同，值越大越先执行）
select_type
表示 SELECT 的类型，常见的取值有 SIMPLE(简单表，即不使用表连接或者子查询)、PRIMARY(主查询，即外层的查询)、UNION(UNION 中的第二个或者后面的查询语句)、SUBQUERY (SELECT/WHERE之后包含了子查询)等
type
表示连接类型，性能由好到差的连接类型为NULL、system、const、eg_ref、ref、range、index、all。
- NULL：不查询表的时候性能为NULL，项目中不可能优化到NULL
- system：查询系统表的时候为system
- const：查询主键或唯一索引时为const
- ref：查询非唯一性的索引为ref
- index：使用了索引，但还是遍历了整个索引树
- all：全表扫描
possible_key
显示可能应用在这张表上的索引，一个或多个
key
表示实际使用的索引，如果为NULL，则没有使用索引。
key_len
表示索引中使用的字节数，该值为索引字段最大可能长度，并非实际使用长度，在不损失精确性的前提下，长度越短越好
rows
MySQL认为必须要执行查询的行数，在innodb引擎的表中，是一个估计值，可能并不总是准确的。
filtered
表示返回结果的行数占需读取行数的百分比，filtered 的值越大越好
extra
额外信息
索引的使用
最左前缀法则
如果索引了多列(联合索引)，要遵守最左前缀法则。最左前缀法则指的是查询从索引的最左列开始，并且不跳过索引中的列。如果跳跃某一列，索引将部分失效(后面的字段索引失效)[索引字段存在即可，在语句中的位置顺序不重要]
比如说：将一张表的name，age，sex字段创建一个联合索引，那么在查找时，name字段必须存在查询条件中，如果不包含name字段，只查询age与sex字段，那么将会全表扫描。如果查询name与sex字段，那么只有name字段会走索引，而sex字段的索引失效，因为跳过了age字段。
范围查询
联合索引中，出现范围查询（>，<），范围查询右侧的索引失效。
比如说，在查询条件中，加入的age>18的条件，那么sex的索引将会失效。
解决方法：在业务允许的情况下，能够使用>=或<=的情况，不要使用>和<。
索引列运算
不要在索引列上进行运算操作，索引将失效。
字符串加引号
如果字符串类型的字段在使用时，不添加引号，那么索引失效。
模糊查询
如果仅仅是尾部模糊匹配，索引不会失效，如果是头部模糊匹配，那么索引失效。
or连接的条件
用or分隔开的条件，如果or前的条件中的列有索引，而后面的列中没有索引，那么涉及的索引都不会被用到。
解决方法：对没有索引的字符也添加索引。
数据分布影响
如果MySQL评估使用索引比全表更慢，则不使用索引。
比如说age>=18，如果表中大多数数据都满足这个条件，那么即使age字段存在索引，那么也不会使用。
当age>=18这个条件表中大多数数据不满足时，才会走索引。
SQL提示
SQL提示，是优化数据库的一个重要手段，简单来说，就是在SQL语句中加入一些人为的提示来达到优化操作的目的。
比如说，name字段存在单列索引，也和age、sex存在联合索引，那么在只查询name字段时，可能会走联合索引。此时我们可以人为干预name字段走单例索引。
使用语法
# use index 在搜索时使用该索引
explain select * from 表名 use index(索引名) where ……;
# ignore index 在搜索时不使用该索引名
explain select * from 表名 ignore index(索引名) where ……;
# force index 强制使用该索引
explain select * from 表名 force index(索引名) where ……;覆盖索引
尽量使用覆盖索引（查询中使用了索引，并且需要返回的列，在该索引中已经全部能够找到），减少select *的使用。
比如说：name与age字段建立了索引在查找语句时where里对name与age进行条件查询，在返回的字段中只填写name、age字段那么在使用explain查看SQL执行计划时，extra字段的信息显示的时using where;using index（可能会随着MySQL版本不同而显示不同）。
如果返回的字段为name、age与sex字段，但是没有在where里使用sex字段，即使sex建立了索引extra显示的信息也为using index condition。
- using where;using index：使用了索引，但是需要的数据在索引列中可以找到，不需要进行回表查询
- using index condition：使用了索引，但是需要回表查询
前缀索引
当字段类型为字符串(varchar，text等)时，有时候需要索引很长的字符串，这会让索引变得很大，查询时，浪费大量的磁盘IO，影响查询效率。此时可以只将字符串的一部分前缀，建立索引，这样可以大大节约索引空间，从而提高索引效率。
语法：
# 最对应字段的后面括号中指定前多少字符建立索引
create index idx_xxx on table_name(column(n));前缀长度的选择：
可以根据索引的选择性来决定，而选择性是指不重复的索引值（基数）和数据表的记录总数的比值，索引选择性越高则查询效率越高，唯一索引的选择性是1，这是最好的索引选择性，性能也是最好的。
# 计算选择性
select count(distinct 字段) / count(*) from 表名;
# 计算前五个字符当索引的选择性
select count(distinct substring(字段,1,5)) / count(*) from 表名;前缀索引查询流程
首先，根据创建索引时指定的索引长度，截取条件中的的对应长度字符取索引中获取第一次出现该索引的id，然后区聚集索引中根据id获取到行信息，从行信息中获取对应字段信息与语句中的信息对比，如果相同，则返回该行信息。如果不同，则在辅助索引中链表中向后查询有无相同的索引，如果没有，则返回空。
索引设计原则
- 针对于数据量较大(百万级时)，且查询比较频繁的表建立索引。
- 针对于常作为查询条件 (where)、排序(order by)、分组 (group by) 操作的字段建立索引。
- 尽量选择区分度高（比如说手机号，邮箱等）的列作为索引，尽量建立唯一索引，区分度越高，使用索引的效率越高。
- 如果是字符串类型的字段，字段的长度较长，可以针对于字段的特点，建立前缀索引。
- 尽量使用联合索引，减少单列索引，查询时，联合索引很多时候可以覆盖索引，节省存储空间，避免回表，提高查询效率。
- 要控制索引的数量，索引并不是多多益善，索引越多，维护索引结构的代价也就越大，会影响增删改的效率。
- 如果索引列不能存储NULL值，请在创建表时使用NOT NULL约束它。当优化器知道每列是否包含NULL值时，它可以更好地确定哪个索引最有效地用于查询。
SQL优化
insert优化
- 选择批量插入：当一条一条语句进行插入时，需要频繁的向数据库建立连接，释放连接，性能较低。其次，批量插入时，尽量选择一次插入500到1000条数据，当插入的数据过多时，建议选择将一条语句拆分成多条语句。
- 手动事务提交：MySQL中，默认的事务提交规则是自动提交，每执行一条语句就需要开启事务，提交事务。频繁的开始事务与提交事务也会损耗性能。
- 主键顺序插入：与表数据存储结构有关，具体原因查看主键优化。
大批量插入数据时比如说百万级数据，使用insert性能不高，可以选择另一个指令load
# 客户端连接服务端时，加上参数 --local-infile。意为需要加载本地文件
mysql --local-infile -u root -p
# 设置全局参数local infile为1，开启从本地加载文件导入数据的开关
set global local_infile = 1;
# 执行load指令将准备好的数据，加载到表结构中
load data local infile '/root/sal1.log' into table 'tb_user' fields terminated by ',' lines terminated by '\n';
#意思是将/root/sal1.log文件加载到tb_user表中，字段之间使用,分隔，数据之间使用\n分隔。主键优化
在InnoDB中，表数据都是根据主键顺序组织存放的，这种存储方式的表称为索引组织表。
我们之前说到，主键索引的存储结构如下图所示
非叶子节点起到索引数据的作用，而叶子节点存储数据。而无论非叶子节点还是叶子节点都是存放在page当中的。接下来，我们基于page查看向表中插入数据的流程
页分裂
首先我们需要知道，page可以为空，也可以填充一半，也可以全部填充。每个页至少包含2条数据（如果一条数据过大，会出现行溢出现象）。
先来查看一种主键顺序插入的情况
当一个页中已经无法满足主键为9的数据插入时，会申请第二个页，来存放主键为9的数据。
最后插入情况如下所示。
如果主键乱序插入的话，则是另一种情况
在已经插入好的数据中，需要插入主键为50的数据，此时，第一个页当中不满足将主键为50的数据插入。
此时，会开辟第三个页，并且将第一个页中超过百分之五十之后的数据移动到第三个页当中，并将主键为50的数据插入到第三个页当中。
此时，需要修改链表指针连接，修改结果如下
乱序插入时，出现的情况就是页分裂。
页合并
当删除一行数据时，时间上数据并没有被物理删除，而是会被标记(flaged)为被删除数据，被标记的数据空间可以被其他数据使用。
当页中被删除的数据达到页合并阈值时（默认为页的百分之50），InnoDB会开始寻找最靠近的页（前或后），查看是否可以将两个页合并以优化空间使用。
比如说，下图中，第二个页中的主键为13，14，15，16的数据已经被标记删除了，被删除数据达到页合并阈值。
主键设计原则
在满足业务需求的情况下，尽量降低主键的长度。这是从索引的角度考虑，二级索引会存储主键信息，当索引过多时，会需要额外的磁盘IO。
插入数据时，尽量选择顺序插入，选择使用AUTO-INCREMENT自增主键。这是为了避免页分裂。
尽量不要使用UUID做主键，或者是其他自然主键，如身份证号。
在业务操作时，尽量避免对主键的修改
order by优化
首先需要解释EXPLAIN中Extra字段的两个值
- Using filesort：通过表的索引或全表扫描，读取满足条件的数据行，然后在排序缓冲区sort buffer中完成排序操作，所有不是通过索引直接返回排序结果的排序都叫FileSort排序。
- Using index：通过有序索引顺序扫描直接返回有序数据，这种情况即为using index，不需要额外排序，操作效率高。
当我们需要对字段进行排序时，如果可以通过索引直接返回，此时效率高。
比如说，我们对一张user表的user与phone建立联合索引。默认的排序方式为升序，此时，我们执行order by user,phone。就是通过索引直接返回的数据。
但是如果执行order by user asc,phone desc。那么无法通过索引直接返回结果，需要对user相同的数据进行phone倒序排列，此时效率就低。又或是执行order phone,user。这样也是无法通过索引直接返回结果的。
使用Order By 的注意事项：
- 根据排序字段建立合适的索引，多字段排序时，也遵循最左前缀法则。
- 尽量使用覆盖索引。
- 多字段排序,一个升序一个降序，此时需要注意联合索引在创建时的规则(ASC/DESC)。
- 如果不可避免的出现filesort，大数据量排序时，可以适当增大排序缓冲区大小sort_buffer_size(默认256k)。
group by优化
在使用分组操作时，如果不是通过索引获取的数据，那么EXPLAIN中的Extra字段会出现Using temporary，意为使用临时表。这种效率不高。
比如说我们对user表中的age与sex建立联合索引，当我们执行
select age,sex,count(*) from user group by age,sex;
时，我们可以通过索引拿到对应的数据，因此效率就高，如果执行
select age,sex,count(*) from user group by sex;
时，不满足最左前缀法则，因此需要走临时表，但是如果执行的是
select age,sex,count(*) from user where age =18 group by sex;
时，走的也是索引，因为我们对age进行了过滤，用到了age索引。
limit优化
在执行limit时，需要将返回的数据之前的数据进行排序后，在返回，比如说返回limit 1000000,10。我们只需要返回1000000-1000010数据，但是需要排序1000010个数据。这样会造成极大的损失。对limit的优化，官方推荐覆盖查询加子查询的方式。比如说user表中存在500w数据，我需要返回2000000-2000010条数据，我只需要这十条数据的id即可，通过执行
select * from user limit 2000000,10;
通过索引拿到10条数据的id。然后通过另一条查询语句获取这十条数据的信息。
需要注意的是，limit不支持在in()中执行，因此我们只能通过多表查询的方式进行查询。具体语句为
select u.* from user u,(select id from user limit 2000000,10) l where l.id = u.id;
count优化
在MyISAM引擎当中，把一个表的总行数存储在了磁盘上，因此在执行count(*)时，会直接返回这个数。
但在InnoDB中没有，它需要一行行读取数据后，累计计数返回。
对于count并没有很好的优化方案。我们可以选择自己计数。比如说我们可以基于内存的key，value数据结构的数据库比如Redis自己保存记录条数。执行insert时就加1。
count的使用
count(主键)：统计总记录数。
InnoDB会遍历整张表，把每一行的主键id取出来，返回给服务层。服务层拿到主键后，直接按行进行累加。
count(字段)：统计该字段不为NULL的数量。
- 没有not null 约束：InnoDB 引擎会遍历整张表把每一行的字段值都取出来，返回给服务层，服务层判断是否为null，不为null，计数累加。
- 有not null约束：InnoDB 引擎会遍历整张表把每一行的字段值都取出来，返回给服务层，直接按行进行累加。
count(1)：只要查询一条记录不为null。那么便返回1。
InnoDB引擎遍历整张表，但不取值。服务层对于返回的每一行，放一个数字“1”进去，直接按行进行累加。
count(*)：记录总记录数。
InnoDB不会把全部字段取出来，而是进行了优化，不取值，服务层直接按行进行累加。
update优化
update的优化主要在于MySQL中使用的是表级锁还是行级锁。
比如说有张user表，存在id与name字段，此时除了id没有其他索引。加入现在并发两条sql语句如下
update user set name = "张三" where id =1;
update user set name = "李四" where id =2;
此时不会有任何问题，因为InnoDB是支持行级锁的，第一条SQL语句锁住的是id为1的数据，而第二条SQL锁住的是id为2的数据，他们互不干扰。
那么接下来如果并发如下语句
update user set name = "张三" where id =1;
update user set name = "李四" where name = "王五";
第一条语句还是锁住id为1的数据。但是第二条数据需要锁住整张表，因为name字段没有索引，需要整表扫描。此时其他sql语句就无法接着进行。
InnoDB的行锁是针对索引加锁，不是针对记录加锁，并且索引不能失效。否则会从行锁升级到表锁。