目录
1.表的设计优化
2.索引优化
2.1 索引创建的规则
2.2 索引失效的场景
3.SQL语句优化
4.主从复制、读写分离
5.分库分表
5.1.怎么判断项目是需要分库还是要分表？
5.2 分库分表有哪些拆分方案？
5.2.1 垂直分库
5.2.2 垂直分表
5.2.3 水平分库
5.2.4 水平分表
5.3 分库分表带来的问题
6.面试回答
SQL可以分为以下5个方面，下面我会挨个阐述：
1.表的设计优化
2.索引优化
3.sql语句优化
4.主从复制、读写分离
5.分库分表
1.表的设计优化
参考了阿里的开发手册（嵩山版）
例如：
①比如设置合适的数值（tinyint，int，bigint），要根据实际情况选择
②比如设置合适的字符串类型（char和varchar）char定长效率高，varchar可变长度，效率稍低
等
2.索引优化
遵循索引创建的规则，避免索引失效的场景
2.1 索引创建的规则
1.针对于数据量较大，且查询比较频繁的表建立索引。单表超过10万数据（增加用户体验）。
2.针对于常作为查询条件（where）、排序（orderby）、分组（groupby）操作的字段建立索引。
3.数据库中大量重复的列不应该建立索引，例如性别。
4.长文本字段使用前缀索引，或者放入es中。
如果是字符串类型的字段，字段的长度较长，可以针对于字段的特点，建立前缀索引（选取字符串前几个字符）。
5.尽量使用联合索引，减少单列索引，查询时，联合索引很多时候可以覆盖索引，节省存储空间，避免回表，提高查询效率
6.索引并不是越多越好，索引越多，维护索引结构的代价也就越大，会影响增删改的效率。
频繁更新的表不应该建立索引，对于频繁进行插入、更新和删除操作的表，索引会导致额外的维护开销，因为每次数据变更时都需要更新索引，这会影响性能。
7.如果索引列不能存储NULL值，请在创建表时使用NOT NULL约束它。当优化器知道每列是否包含NULL值时，它可以更好地确定哪个索引 最有效地用于查询
8.数据库较小的表，不要建立索引，因为可能走全表扫描
2.2 索引失效的场景
1 使用了联合索引却不符合最左前缀匹配原则
举个例子：小鱼对 user 表建立了一个联合索引为 name_age_id 的联合索引。 他使用以下 SQL 查询select * from user where age = 10 and id = 1; 这样的写法恰恰不满足最左前缀原则，索引就失效啦。
详细解释：
MySQL中，索引的“最左前缀原则”是指在使用索引进行查询时，索引会从左到右匹配列。如果查询条件中包含了索引的最左列，那么索引就可以被使用；如果没有包含最左列，那么索引可能不会被使用。
在上面例子中，小鱼建立了一个名为
name_age_id的联合索引，这意味着索引的顺序是name、age和id。这个索引可以支持以下几种查询条件：
- 仅
name列：WHERE name = '某个值'name和age列：WHERE name = '某个值' AND age = 某个值name、age和id列：WHERE name = '某个值' AND age = 某个值 AND id = 某个值但是，如果查询条件只包含
age和id，而不包含name，那么索引可能不会被使用，因为name是索引的最左列。这是因为索引的最左前缀原则要求查询条件必须包含索引的最左列。
2.索引中使用了运算
例如这个 SQL select * from user where id + 3 = 8。这样会导致全表扫描计算 id 的值再进行比较，使得索引失效。
3. 索引上使用了函数也会失效
例如：select * from user where LOWER(name) like 'cong%';。这样也会导致索引失效，索引参与了函数处理，会导致去全表扫描。
4. 以%开头的Like模糊查询
如果仅仅是为有模糊匹配，索引不会失效
5. or的随意使用，必须or的两个字段，都有索引，索引才会生效
user 当前只有一个索引 name 。此时执行以下SQL ：select * from user where name= 'cong' or age = 18; 这也会导致索引失效，因为 age 没有索引。
6. 隐式类型转换，会导致索引失效
例如：字符串不加' ',隐式的类型转换会导致索引失效
不小心将 varchar 类型的 name 条件匹配了 int 类型字段。
SQL 是这样的 select * from user where name = 1;
正确的应该写为select * from user where name = '1';
7.表中两个不同的字段进行比较，索引会失效
例如这样的SQL :select * from user where id > age; ，将 id 跟 age 字段做了比较，索引失效！
8.使用了 is not null
注意使用了 is not null 会直接导致失效，而使用 is null 则不会。因为当使用 is not null 条件时，数据库系统需要扫描整个索引，找出所有不为 null 的值，这可能会导致索引失效。使用 is null条件不会导致索引失效，因为对于索引而言，查找 null 值的行与查找其他任何特定值的行都没有本质区别。在大多数情况下，null 值都会被索引包括在内。
9.使用了 order by，但后面不跟主键
当 order by 后面跟的 不是主键 或者 不是覆盖索引 会导致不走索引。
10.使用了 != 、<>，可能导致索引失效
例如这样的 SQL ：select * from user where name != 'cong' ，
如果name列的值大多数都是'cong'，那么不等于'cong'的记录可能很少，优化器可能会认为使用索引不划算，因此选择全表扫描。这种情况下，索引可能不会生效。
3.SQL语句优化
- SELECT语句务必指明字段名称（避免直接使用select＊）
- SQL语句要避免造成索引失效的写法（2.2 索引失效的场景）
- 尽量用union all代替union ，union会多一次过滤，效率低
上面两个sql使用union all连接则第二个sql重复的值也会被返回，使用union会多一次过滤，过滤掉第二个sql重复的值
4.Join优化：能用inner join就不用left join、right oin，如必须使用一定要以小表为驱动，
内连接会对两个表进行优化，优先把小表放到外边，把大表放到里边。left join 或right join，不会重新调整顺序
4.主从复制、读写分离
主从复制、读写分离（分库）解决的是访问的压力，不能解决海量数据的存储，海量数据存储需要用到分库分表
5.分库分表
当MySQL单表数据量过大，比如数据量超过1千万条或者储存量达到20G的时候，读写性能变得很差。而且常规的优化手段已经不起作用了，比如：SQL调优、添加索引、主从复制、读写分离。这时候就需要用到MySQL终极优化方案 — 分库分表。
5.1.怎么判断项目是需要分库还是要分表？
（分库解决的是访问的压力，分表解决的是海量数据存储）
1.当单表数据量过大，读写性能较差，就需要分表。
2.当数据库的QPS过高，数据库连接数不足的时候，就需要分库。
3.当两者都有的时候，就需要分库分表。
5.2 分库分表有哪些拆分方案？
分库分表有垂直拆分和水平拆分。垂直拆分又有垂直分库、垂直分表。
5.2.1 垂直分库
垂直分库，不同的业务拆分到不同的数据库。
5.2.2 垂直分表
垂直分表，把长度较大或者访问频次较低的字段，拆分到扩展表中。
5.2.3 水平分库
水平分库是把同一个表的数据按一定规则拆到不同的数据库中，每个库可以放在不同的服务器上。
5.2.4 水平分表
5.3 分库分表带来的问题
更详细的可以看这篇文章第四条
Mysql分库分表 面试题（待补充完善）_mysql分库分表面试题-CSDN博客
6.面试回答
