分页查询优化
select * from employee limit 10000,10
对于上面的额sql语句，执行过程底层从1开始到10000数据进行扫描分页查询，雄安率比较低
select * from employees where id > 90000 limit 5;
优化：对于主键自增连续的，可以按照主键去查询从第90001开始的五行数据,没有指定排序order by的化默认是按照主键排序。
范围限定之后再去取值 排序 前提是主键自增-----实际应用过程中条件比较
第一条sql语句，没有用到索引，而且用到文件排序。第二条sql语句，用到了索引而且没有用到文件排序，效率会高很多
Join关联优化查询
小表驱动大表 执行过程实际上是先执行小表中的结果，然后再关联大表中的数据
EXPLAIN SELECT * FROM t1 inner join t2 on t1.a = t2.a;
对于上面的sql语句小表t1是100条数据，大表t2是10000条数据，t1表走全表扫描，t2表走的是索引，由于t1表表中的数据相当小，扫描很快，因此在驱动t2表中的记录的时候很快，相当于直接关联通过t1表直接查询
嵌套循环链接算法
从一张表中查询所有的记录，再去另一张表中用索引关联查询
基于块的嵌套循环连接
把驱动表的数据读入到join_buffer中，然后扫描被驱动表，把被驱动表每一行取出来跟join_buffer中的数据进行对比 这种情况下，假如小表t1中有100条数据，大表中有10000条数据，过滤完小表中的100条数据之后放入join_buffer中，之后再用大表中10000条数据根据join_buffer中的结果进行对比，不过极端情况下，可能出现对比10000*100的情况。 join_buffer默认256k---数据量大的话分段存储
内存计算跟磁盘扫描是差了数量级的，内存计算会快的多，在没有索引的情况下BNL这种算法更快一点，有索引的情况下用NLJ算法
关联字段，尽量的加索引特别是被驱动表，一般选择小表做驱动表，大表被驱动表关联的时候走索引 先执行的表尽量是小表，后执行的表尽量是大表
对于关联查询的优化
关联字段加索引 小表驱动大表--大表走索引，小表走不走索引无所谓 定义的小表还是大表是定义的关联的结果集，并不是根据数据量来的
in和exist
优化原则，小表驱动大表--小的结果集驱动大的结果集 in :当B表的数据集小于A表的数据集的时候，in优于exist
exist：当A表的数据集小于B表的数据集的时候，exist优于in
Count()查询优化
上面4条sql语句执行效率其实差不多
- 字段有索引：count(*) ~~ count(1)>count(字段) >count(主键) 在字段有索引的情况下，count字段统计走二级索引，二级索引存储数据比主键索引少，所以count(字段)>count(主键)
- 字段无索引：count(*) ~~ count(1)>count(主键) >count(字段) //字段没有索引count（字段）走不了索引，count(主键 id)可以走主键索引
常见的优化方法
-
对于MyISam存储引擎
select count(*) from test_myisam;在MyiSAM存储引擎中，数据集会被mysql存储在磁盘上维护好，查询不需要计算，但是Innodb是不会维护count(*)的（因为有MVCC机制--不同的事务读取出来的结果集不一样），查询count需要实时计算 -
show table status
如果是InnoDB的表想要快速的查找结果集，如果对总结果集要求不是很高的话，可以使用
show table status 'employees';.
但是如果对结果集要求比较高的话，可以把总数维护在redis中，在redis中维护一个原子计数器，在数据库中insert一条语句，后缀值+1，删除一条记录—1 不过缓存和数据库数据很难达到一致，缓存数据库要实现一致，实现起来代价非常高
对于分布式事务不可能100%达到一致
- 增加数据库技术表，把总数维护在数据库里面，利用数据库的本地事务来实现数据的一致性，基本上可以达到100%数据一致
插入或者删除表数据行的时候维护计数表，让他们在同一个事务里面操作
阿里巴巴手册
对于单表行数超过500万行或者单表荣来给你超过2GB，才推荐使用分库分表
如果预计三年后的数据量根本达不到这个级别，不要在创建表时分库分表
不用一开始创建数据库的时候就考虑分库分表。上面只是一个推荐，根据推荐效率可以达到最优
索引规约
- 业务上具有唯一特性的字段，即使是组合字段，也必须建成唯一索引
- 从数据库层面做约束，从代码层面做约束太困难，不能保证每一个程序员都能做到维护
- 对于损耗来说，数据的绝对一致性更重要
- 超过三个表禁止join。需要join的字段，数据类型保持绝对的一致；多表关联查询时，保证被关联的字段需要有索引
-
表关联优化很难，对于联表优化根据Explain，大表一定要走索引；就算优化得很好，每张表参与优化的数据量很大，可能造成笛卡尔积等问题.....
-
能用java实现优化尽量用Java实现，因为MySQL是不容易扩展到的，但是对于Java来说可以横向扩容、做集群、做分布式
oracle扩展性不如Mysql
- like %优化，走覆盖索引或者使用搜索引擎
4. 推荐：in操作能避免则避免，实在避免不了，需要仔细的评估in后面的集合元素数量，控制在1000以内。in操作跟表事务数据量是有关的，数据表记录少的话走不走索引的无所谓，数据记录大的话按照上面推荐
5. 因国际化需要，所有的字符存储与表示，均采用utf8字符集（一个字符3个字节），如果需要存储表情（占4个字节），那么选择utf8mb4来进行存储
Mysql数据类型选择
mysql中选择正确的数据类型，对于性能至关重要，一般遵循下面两步：
- 确定合适的大类型：数字，字符串，时间，二进制
- 确定具体的类型：有无符号，取值范围，变长还是定长等
在Mysql数据类型设置方面尽量选择更小的数据类型，因为他们通常有更好的性能，话费更少的数据资源。并且尽量把字段定义为not null，避免使用null
1、数值类型
| 类型 | 大小 | 范围（有符号） | 范围（无符号） | 用途 |
| TINYINT | 1 字节 | (-128, 127) | (0, 255) | 小整数值 |
| SMALLINT | 2 字节 | (-32 768, 32 767) | (0, 65 535) | 大整数值 |
| MEDIUMINT | 3 字节 | (-8 388 608, 8 388 607) | (0, 16 777 215) | 大整数值 |
| INT或INTEGER | 4 字节 | (-2 147 483 648, 2 147 483 647) | (0, 4 294 967 295) | 大整数值 |
| BIGINT | 8 字节 | (-9 233 372 036 854 775 808, 9 223 372 036 854 775 807) | (0, 18 446 744 073 709 551 615) | 极大整数值 |
| FLOAT | 4 字节 | (-3.402 823 466 E+38, 1.175 494 351 E-38)，0，(1.175 494 351 E-38，3.402 823 466 351 E+38) | 0, (1.175 494 351 E-38, 3.402 823 466 E+38) | 单精度浮点数值 |
| DOUBLE | 8 字节 | (1.797 693 134 862 315 7 E+308, 2.225 073 858 507 201 4 E-308), 0, (2.225 073 858 507 201 4 E-308, 1.797 693 134 862 315 7 E+308) | 0, (2.225 073 858 507 201 4 E-308, 1.797 693 134 862 315 7 E+308) | 双精度浮点数值 |
| DECIMAL | 对DECIMAL(M,D) ，如果M>D，为M+2否则为D+2 | 依赖于M和D的值 | 依赖于M和D的值 | 小数值 |
优化建议
- 如果整形数据没有负数，如ID号，建议指定为UNSIGNED无符号类型，容量可以扩大一倍。
- 建议使用TINYINT代替ENUM、BITENUM、SET。
- 避免使用整数的显示宽度(参看文档最后)，也就是说，不要用INT(10)类似的方法指定字段显示宽度，直接用INT。
- DECIMAL最适合保存准确度要求高，而且用于计算的数据，比如价格。但是在使用DECIMAL类型的时候，注意长度设置。
- 建议使用整形类型来运算和存储实数，方法是，实数乘以相应的倍数后再操作。
- 整数通常是最佳的数据类型，因为它速度快，并且能使用AUTO_INCREMENT。
2、日期和时间
| 类型 | 大小(字节) | 范围 | 格式 | 用途 |
| DATE | 3 | 1000-01-01 到 9999-12-31 | YYYY-MM-DD | 日期值 |
| TIME | 3 | '-838:59:59' 到 '838:59:59' | HH:MM:SS | 时间值或持续时间 |
| YEAR | 1 | 1901 到 2155 | YYYY | 年份值 |
| DATETIME | 8 | 1000-01-01 00:00:00 到 9999-12-31 23:59:59 | YYYY-MM-DD HH:MM:SS | 混合日期和时间值 |
| TIMESTAMP | 4 | 1970-01-01 00:00:00 到 2038-01-19 03:14:07 | YYYYMMDDhhmmss | 混合日期和时间值，时间戳 |
优化建议
- MySQL能存储的最小时间粒度为秒。
- 建议用DATE数据类型来保存日期。MySQL中默认的日期格式是yyyy-mm-dd。
- 用MySQL的内建类型DATE、TIME、DATETIME来存储时间，而不是使用字符串。
- 当数据格式为TIMESTAMP和DATETIME时，可以用CURRENT_TIMESTAMP作为默认（MySQL5.6以后），MySQL会自动返回记录插入的确切时间。
- TIMESTAMP是UTC时间戳，与时区相关。
- DATETIME的存储格式是一个YYYYMMDD HH:MM:SS的整数，与时区无关，你存了什么，读出来就是什么。
- 除非有特殊需求，一般的公司建议使用TIMESTAMP，它比DATETIME更节约空间，但是像阿里这样的公司一般会用DATETIME，因为不用考虑TIMESTAMP将来的时间上限问题。
- 有时人们把Unix的时间戳保存为整数值，但是这通常没有任何好处，这种格式处理起来不太方便，我们并不推荐它。
3、字符串
| 类型 | 大小 | 用途 |
| CHAR | 0-255字节 | 定长字符串，char(n)当插入的字符数不足n时(n代表字符数)，插入空格进行补充保存。在进行检索时，尾部的空格会被去掉。 |
| VARCHAR | 0-65535 字节 | 变长字符串，varchar(n)中的n代表最大字符数，插入的字符数不足n时不会补充空格 |
| TINYBLOB | 0-255字节 | 不超过 255 个字符的二进制字符串 |
| TINYTEXT | 0-255字节 | 短文本字符串 |
| BLOB | 0-65 535字节 | 二进制形式的长文本数据 |
| TEXT | 0-65 535字节 | 长文本数据 |
| MEDIUMBLOB | 0-16 777 215字节 | 二进制形式的中等长度文本数据 |
| MEDIUMTEXT | 0-16 777 215字节 | 中等长度文本数据 |
| LONGBLOB | 0-4 294 967 295字节 | 二进制形式的极大文本数据 |
| LONGTEXT | 0-4 294 967 295字节 | 极大文本数据 |
优化建议
- 字符串的长度相差较大用VARCHAR；字符串短，且所有值都接近一个长度用CHAR。
- CHAR和VARCHAR适用于包括人名、邮政编码、电话号码和不超过255个字符长度的任意字母数字组合。那些要用来计算的数字不要用VARCHAR类型保存，因为可能会导致一些与计算相关的问题。换句话说，可能影响到计算的准确性和完整性。
- 尽量少用BLOB和TEXT，如果实在要用可以考虑将BLOB和TEXT字段单独存一张表，用id关联。
- BLOB系列存储二进制字符串，与字符集无关。TEXT系列存储非二进制字符串，与字符集相关。
- BLOB和TEXT都不能有默认值。
PS：INT显示宽度
我们经常会使用命令来创建数据表，而且同时会指定一个长度，如下。但是，这里的长度并非是TINYINT类型存储的最大长度，而是显示的最大长度。
CREATE TABLE user( id TINYINT(2) UNSIGNED );
这里表示user表的id字段的类型是TINYINT，可以存储的最大数值是255。所以，在存储数据时，如果存入值小于等于255，如200，虽然超过2位，但是没有超出TINYINT类型长度，所以可以正常保存；如果存入值大于255，如500，那么MySQL会自动保存为TINYINT类型的最大值255。
在查询数据时，不管查询结果为何值，都按实际输出。这里TINYINT(2)中2的作用就是，当需要在查询结果前填充0时，命令中加上ZEROFILL就可以实现，如：
id TINYINT(2) UNSIGNED ZEROFILL
这样，查询结果如果是5，那输出就是05。如果指定TINYINT(5)，那输出就是00005，其实实际存储的值还是5，而且存储的数据不会超过255，只是MySQL输出数据时在前面填充了0。
换句话说，在MySQL命令中，字段的类型长度TINYINT(2)、INT(11)不会影响数据的插入，只会在使用ZEROFILL时有用，让查询结果前填充0。
