可有可无的Mysql工作技巧

跨节点Join的问题

只要是进行切分，跨节点Join的问题是不可避免的。但是良好的设计和切分却可以减少此类情况的发生。解决这一问题的普遍做法是分两次查询实现。在第一次查询的结果集中找出关联数据的id,根据这些id发起第二次请求得到关联数据

跨节点的count,order by,group by以及聚合函数问题

这些是一类问题，因为它们都需要基于全部数据集合进行计算。多数的代理都不会自动处理合并工作。解决方案：与解决跨节点join问题的类似，分别在各个节点上得到结果后在应用程序端进行合并。和join不同的是每个结点的查询可以并行执行，因此很多时候它的速度要比单一大表快很多。但如果结果集很大，对应用程序内存的消耗是一个问题。

记住：任何客户端都要认为不可信任的！

优化建议：

1、MYSQL不适合做统计分析计算使用，手机看板、主动营销、日接单等需要统计的项目，转移到其他数据库去做，否则MYSQL吃不消。

2、BI同步数据的操作，应该通过DTS或BINLOG的方式去同步，不要直接查询方式去同步(查库同步的方式有很多慢SQL)。

3、开发人员写SQL(特别操作大表的)要经过查询计划分析，审计review通过才能上线。

4、集团查看订单列表等大数据量查询的，转移到ES组件去实现，否则拖跨整个服务。

5、要做数据归档，冷数据处理，比如订单进度表目前已经接近6千万行，对于历史超过1年的数据，应该做个归档，否则将会浪费大量宝贵的服务资源，但这些归档的操作需要业务上做个妥协，比如超过一年的数据不再支持查看订单进度（其实已经是安装过的订单，再去查看订单进度已经没有意义了！）

讲个冷笑话：用户说，你的系统非常的慢。我们说，那是你走的太快了。坐下来，喝个茶，再打一局王者就好了。

就读于清华的良友说，有些东西是一定要记住的，比如基本的定律。诚然，依赖记性不是长久的办法。但是，必须要有能记住事情的大脑。

5 问题
将时间转换为时间戳，并使用 int 或者 bigint 类型去存储，你觉得这样可行吗？
大多数时候，我们会选择将主键设置为 bigint 数据类型，你知道这是为什么吗？

：第一个问题，是否可以考虑将时间存储为整型？这是完全可以的，正如你所说，时间是整型的话，前端可以方便的进行转换，而且不用考虑精度的问题，且这种转换带来的性能损耗几乎是可以忽略不计的。当然，如果仅仅是 java 系统之间使用的话，使用 datetime 存储是最方便的，序列化和反序列化都只需要一个注解就可以完成。第二个问题，为什么考虑将主键设置为 binint 类型？这里的主要思想就是为了将来的扩展，因为 int 类型的最大表示范围大约是 20 亿，这对于 99% 的项目都基本足够用了。但是，如果考虑到将来业务发展的比较迅速，就需要使用 bigint 了。如果一开始没有使用 bigint，而是使用 int，那么，后期的迁移将会是很大的工作量

在工作中，解决各种错误、性能问题的同时，一定要注意多做笔记，多做总结。并在这个过程中，
将自己懂得的知识点、技巧、优化方案等等输出出去，帮助其他同学共同进步。

如何定义快与慢呢？

慢，所谓慢，不够快；那什么是快，不慢（-- 废话文学）

MySQL 服务器在 CPU 和 IO 层面存在瓶颈：

数据装入内存或从磁盘上读取数据时， CPU 使用率会迅速提升，此时会影响到查询或计算
需要载入的数据远远大于内存容量的时候，服务器就不得不使用 “ 交换策略 ” 往返于内存和磁盘之间

慢查询的表现归纳为以下三点：

查询带有大数据量返回，服务器到客户端的返回需要通过网络传输，大数据量的传输无疑会消耗大量的时间
发出请求到响应的时间差值超过 1s （更具体的，要结合实际业务定义阈值）的查询
CPU 和内存瞬时使用率过高，服务器压力陡然增大，大概率是慢查询导致。

SELECT 太多数据行、数据列（大数据量查询）
没有按照索引列定义的顺序查询（虽然 SQL 优化器可能会根据索引字段的顺序调整我们的查询语句，但是，不应该依赖于优化器）

定义了索引，但是 MySQL 并没有选择我们来总结下优化器不使用索引的一些情况和解决办法：

在索引列上进行函数计算，优化器大概率不会使用索引。最好的解决办法就是将计算过程转移到代码中去
模糊查询（ LIKE ） % 在前面的情况，优化器不能确定前缀，无法使用索引。可以考虑在代码中做过滤
存在 OR 条件连接，会导致后续条件无法使用索引。可以将 OR 修改为 UNION ALL
对于时间范围索引，查询的时间跨度很大，接近于全表扫描，优化器会放弃索引。这样的查询往往是不合理的，应该避免
索引列存在 NULL 值，维护、使用索引都很费资源，优化器很可能会放弃。索引列一定要 NOT NULL ，可以填入 “ 非法值

3.4 没有定义索引
查询找不到索引时， MySQL 不得不扫描全表，导致大量慢查询的出现。但是，解决没有索引导致的慢查询问题，大多数时候，不是加上一个索引这么简单的。我在工作中就遇到过类似的问题：业务系统中的一张核心数据表，数据记录数超过了 3000 万行，经常由于找不到合适的索引而出现慢查询。但是，如果给它加上索引，会导致锁表时间（创建索引期间， MySQL 会获取到表锁，再去执行操作）过长，影响线上业务。

那么，对于没有索引的情况，我们可以考虑以下的方法解决：

1 直接创建需要的索引，但是这仅当表中的数据量不大，不影响正常业务运转的情况下
2 表中数据量过大时，对表进行拆分（并建立必要的索引），对小表进行查询（可能会关联查询）
3 对查询的结果进行缓存，减少对数据表的访问次数

3.5 复杂查询
最合理的方式就是将一个复杂查询拆分为多个简单查询。通常，
在使用到索引时，单表或者两张表的联合查询不会执行很慢。但是，需要特别注意，拆分成多个查询之后，需要把它们都放在一个事务中

1快速学会分析SQL执行效率

查看慢查询日志确定已经执行完的慢查询
show processlist 查看正在执行的慢查询
long_query_time （单位秒，默认值 10 ）
设置的值并且扫描记录数不小于min_examined_row_limit （默认值 0 ）

知识扩展：
MySQL 中 long_query_time 的值如何确定呢？
线上业务一般建议把 long_query_time 设置为 1 秒，如果某个业务的 MySQL 要求比较高的 QPS ，可设置慢查询为 0.1 秒。发现慢查询及时优化或者提醒开发改写。
一般测试环境建议 long_query_time 设置的阀值比生产环境的小，比如生产环境是 1 秒，则测试环境建议配置成 0.5 秒。便于在测试环境及时发现一些效率低的 SQL 。
甚至某些重要业务测试环境 long_query_time 可以设置为 0 ，以便记录所有语句。并留意慢查询日志的输出，上线前的功能测试完成后，分析慢查询日志每类语句的输出，重点关注 Rows_examined （语句执行期间从存储引擎读取的行数），提前优化。

工具：pt-query-digest 或者 mysqldumpslow 等工具对慢查询日志进行分

explain 、 show profile 和 trace 等诊断工具来分析慢查询
比如语句是否使用了关联查询、是否使用了索引、扫描行数等

Explain 的结果各字段解释如下（务必记住）

列名解释
id 查询编号

select_type 查询类型：显示本行是简单还是复杂查询
table 涉及到的表
partitions 匹配的分区：查询将匹配记录所在的分区。仅当使用 partition 关键字时才显示该列。对于非分区表，该值为 NULL 。

type 本次查询的表连接类型

possible_keys 可能选择的索引

key 实际选择的索引

key_len 被选择的索引长度：一般用于判断联合索引有多少列被选择了
ref 与索引比较的列

rows 预计需要扫描的行数，对 InnoDB 来说，这个值是估值，并不一定准确

filtered 按条件筛选的行的百分比

Extra 附加信息

2.1 select_type（熟记）：显示本行是简单还是复杂查询

select_type 的值解释
SIMPLE 简单查询 ( 不使用关联查询或子查询 )
PRIMARY 如果包含关联查询或者子查询，则最外层的查询部分标记为 primary
UNION 联合查询中第二个及后面的查询
DEPENDENT UNION 满足依赖外部的关联查询中第二个及以后的查询
UNION RESULT 联合查询的结果
SUBQUERY 子查询中的第一个查询
DEPENDENT SUBQUERY 子查询中的第一个查询，并且依赖外部查询
DERIVED 用到派生表的查询
MATERIALIZED 被物化的子查询
UNCACHEABLE SUBQUERY 一个子查询的结果不能被缓存，必须重新评估外层查询的每一行
UNCACHEABLE UNION 关联查询第二个或后面的语句属于不可缓存的子查询

2.2 type （熟记） type 本次查询的表连接类型

下表的这些情况，查询性能从上到下依次是最好到最差。
type 的值解释
system 查询对象表只有一行数据 , 且只能用于 MyISAM 和 Memory 引擎的表，这是最好的情况

const 基于主键或唯一索引查询，最多返回一条结果

eq_ref 表连接时基于主键或非 NULL 的唯一索引完成扫描

ref 基于普通索引的等值查询，或者表间等值连接

fulltext 全文检索

ref_or_null 表连接类型是 ref ，但进行扫描的索引列中可能包含 NULL 值

index_merge 利用多个索引

unique_subquery 子查询中使用唯一索引

index_subquery 子查询中使用普通索引

range 利用索引进行范围查询
index 全索引扫描
ALL 全表扫描

2.3 Extra （熟记）附加信息

Extra 常见的值解释例子

Using filesort
将用外部排序而不是索引排序，数据较小时从内存排序，
否则需要在磁盘完成排序explain select * from t1 order by create_time;

Using temporary
需要创建一个临时表来存储结构，通常发生对没有索引的
列进行 GROUP BY 时 explain select * from t1 group by create_time;

Using index 使用覆盖索引 explain select a from t1 where a=111;

Using where 使用 where 语句来处理结果
explain select * from t1 where create_time=‘2019-06-18 14:38:24’;

Impossible WHERE
对 where 子句判断的结果总是 false 而不能选择任何数据 explain select * from t1 where 1<0;

Using join buffer (BlockNested Loop)关联查询中，被驱动表的关联字段没索引
explain select * from t1 straight_join t2 on(t1.create_time=t2.create_time);

Using index condition 先条件过滤索引，再查数据
explain select * from t1 where a >900 and a like“%9”;

Select tables optimized away
使用某些聚合函数（比如 max 、 min ）来访问存在索引的某个字段时。explain select max(a) from t1;

show profile 分析慢查询

知识扩展：可以通过配置参数 profiling = 1 来启用 SQL 分析。该参数可以在全局和 session 级别来设置。对于全局级别则作用于整个 MySQL 实例，而 session 级别仅影响当前 session 。该参数开启后，后续执行的SQL 语句都将记录其资源开销，如 IO 、上下文切换、 CPU 、 Memory 等等。根据这些开销进一步分析当前SQL 从而进行优化与调整

使用 profile 分析慢查询，大致步骤是：确定这个 MySQL 版本是否支持 profile ；确定 profile
是否关闭；开启 profile ；执行 SQL ；查看执行完 SQL 的 query id ；通过 query id 查看 SQL 的每个状态及耗时时间。

trace 分析 SQL 优化器 5.6 +
explain 可以查看 SQL 执行计划，但是无法知道它为什么做这个决策，如果想确定多种索引方案之间
是如何选择的或者排序时选择的是哪种排序模式，有什么好的办法吗？
从 MySQL 5.6 开始，可以使用 trace 查看优化器如何选择执行计划。

开启该功能，会对 MySQL 性能有所影响，因此只建议分析问题时临时开启。

TRACE 字段中整个文本大致分为三个过程。
准备阶段：对应文本中的 join_preparation
优化阶段：对应文本中的 join_optimization
执行阶段：对应文本中的 join_execution

analyzing_range_alternatives
filesort_summary

知识扩展：
知识点一： MySQL 常见排序模式：
< sort_key, rowid > 双路排序（又叫回表排序模式）：是首先根据相应的条件取出相应的排序字段和可以直接定位行数据的行 ID ，然后在 sort buffer 中进行排序，排序完后需要再次取回其它需要的字段；
< sort_key, additional_fields > 单路排序：是一次性取出满足条件行的所有字段，然后在 sort buffer 中进行排序；
< sort_key, packed_additional_fields > 打包数据排序模式：将 char 和 varchar 字段存到 sort buffer 中时，更加紧缩。
三种排序模式比较：
第二种模式相对第一种模式，避免了二次回表，可以理解为用空间换时间。由于 sort buffer 有限，如果需要查询的数据比较大的话，会增加磁盘排序时间，效率可能比第一种方式更低。
MySQL 提供了一个参数： max_length_for_sort_data ，当 “ 排序的键值对大小 ” > max_length_for_sort_data时， MySQL 认为磁盘外部排序的 IO 效率不如回表的效率，会选择第一种排序模式；否则，会选择第二种模式。
第三种模式主要解决变长字符数据存储空间浪费的问题。
知识点二：优化器在估计符合条件的行数时有两个选择：
index diver ： dive 到 index 中利用索引完成元组数的估算；特点是速度慢，但可以得到精确的值；
index statistics ：使用索引的统计数值，进行估算；特点是速度快，但是值不一定准确。

explain ：获取 MySQL 中 SQL 语句的执行计划，比如语句是否使用了关联查询、是否使用了索引、扫描行数等；
profile ：可以清楚了解到 SQL 到底慢在哪个环节；
trace ：查看优化器如何选择执行计划，获取每个可能的索引选择的代价

关于 SQL 查询语句，有什么好的建议吗？

2 条件字段有索引，为什么查询也这么慢
1 函数操作
1.1 验证对条件字段做函数操作是否能走索引
1.2 隐式转换

隐式转换估计是很多 MySQL 使用者踩过的坑，比如联系方式字段。由于有时电话号码带加、减等特殊字符，有时需要以 0 开头，因此一般设计表时会使用 varchar 类型存储，并且会经常做为条件来查询数据，所以会添加索引。而有时遇到需要按照手机号码条件（比如 11111111111 ）去查询数据时，因为查询者看到条件是一串数字，而忽视表中对应手机号字段是 varchar 类型，因此写出了如下不合理的 SQL ：
实际情况这条 SQL 查询效率是很低的。首先根据你的经验，思考下这条 SQL 怎么优化

经验分享：隐式转换导致查询慢的情况在工作中遇到过几次，有时字段名对开发写 SQL 产生了影响，比如曾经遇到过字段名是 user_num
，而实际字段类型是 char ，但是开发在写 SQL 时误认为是 int 型，导致漏写单引号而发生隐式转换。所以建议在写 SQL
时，先看字段类型，然后根据字段类型写 SQL

模糊查询优化建议
发现并不能走 b 字段的索引。
原因：优化器会根据检索比例、表大小、 I/O 块大小等进行评估是否使用索引。比如单次查询的数据量过大，
优化器将不走索引

经验分享：
实际这种范围查询而导致使用不了索引的场景经常出现，比如按照时间段抽取全量数据，每条 SQL 抽取一个月
的；或者某张业务表历史数据的删除。遇到此类操作时，应该在执行之前对 SQL 做 explain 分析，确定能走
索引，再进行操作，否则不但可能导致操作缓慢，在做更新或者删除时，甚至会导致表所有记录锁住，十分
危险

数据类型选择与使用上的技巧与建议

3.1 使用 NOT NULL ，且带有 COMMENT

这个建议适用于所有的数据类型， MySQL 在索引值为 NULL 的列时，需要额外的存储空间，所以，相对于 NOTNULL 来说， NULL 会占用更多的空间。另外，在进行比较和计算时， MySQL 要对 NULL 值做特别的处理，使用效率较低。COMMENT 用于定义列的注释信息，就好像我们在写代码一样，把重要的或者不易理解的地方，加上一些注释，方便以后查阅

3.2 使用存储需要的最小数据类型
3.3 选择简单的数据类
这里的 “ 简单 ” 二字听上去会比较奇怪，我以一个例子去说明。假如说我想在一列中存储 10 、 100 、 201 这样的数据，我们可以选择使用 int 或 varchar 来存储。但是整型要比字符型的操作复杂度小太多，那么，选择整型（例如int ）就是最简单的数据类型
3.4 存储小数直接选择 decimal
虽然我并不建议在数据库中存储小数，但是，在一些场景中小数不可避免，最常见的例子就是订单的金额。由于小数本身在计算时就很复杂，而且很多时候你需要去考虑精度问题。所以，最直接的方式就是把这种管理交给数据库。这里我提出一个扩展建议，也就是不要在数据库中存储小数。那么，假如订单的精度到分（元、角、分）级别，我们可以考虑在存储时，把数据值 * 100 再去存储。之后，在代码中处理分的逻辑，也就是自己去控制处理小数的精度问题。
3.5 尽量避免使用 text 和 blob
MySQL 内存临时表并不支持 text 、 blob 这样的大数据类型，如果查询时包含有这样的数据，则排序操作必须使用磁盘临时表，性能会下降很多。而且对于这种数据， MySQL 还要做二次查询（因为 MySQL 实际保存的是指针，而不是真实数据），会使 SQL 性能变得很差。但是，也并不是说我们一定就不能用 text 和 blob 。如果确实有需求需要使用这样的数据类型，那么在查询时一定不要直接 SELECT * ，而是取出需要的列。这样 MySQL 就不会去主动查询这些数据列，也是提高性能的一种惯用手段。最后，还需要注意，因为 MySQL 对索引长度的限制， text 类型只能用到前缀索引，并且由于存储的是指针， text列上不能有默认值

如果你设计的数据库和数据表能够支撑当前的业务需求，且在技术实现上没有太大的弊端，那么，我们就可以
说它是可用的。更深层的看，这个设计目标的核心其实是对需求的理解。确实，理清了需求，你会得出结论：
应该存储哪些数据、这些数据是什么类型、在代码中怎样使用这些数据等等。余下的建库建表也自然就是水到
渠成了.

好用的设计目标
需求也许不会变化，但是随着业务量的增长触发数据和并发的增长，数据库是否还能保持相对较高的性能是个
值得思考的问题，同时也是衡量设计目标是否好用的重要指标。
无论什么时候，我们对 MySQL （数据库）的使用都肯定是围绕数据的增删改查。而这些基本的操作，当数据
量加速膨胀的过程中，也会引起性能瓶颈。所以，好用的设计目标讲究能够 “ 预见未来 ” ，能够对未来做出预
判。例如：将通用信息单独使用一张表存储、建立适当的索引等等

不要使用物理外键：物理外键是说让数据库去管理表与表之间的关联关系，而它相对的逻辑外键，则是我们自
己用代码去管理这种关系。这是因为物理外键存在两个重大缺陷：消耗数据库资源，降低数据库实例可扩展
性；母表一旦受损，子表很难恢复，造成数据丢失。

所以，没有冗余就未必是好的，有时为了提高工作效率（对于查询大于更新的业务），就必须采用反范式的设计，适当的让数据存在冗余
.

4 让order by、group by查询更快
5 换种思路写分页查询
6 Join语句可以这样优化
7为何count()这么慢

31 MySQL整体优化思路

MySQL 参数配置优化
连接指的是 MySQL 服务器与客户端之间的连接，相关参数的设定主要会影响客户端的行为。例如：是否能够连接上 MySQL 服务器、关闭交互连接前等待的时间等等。

max_connections
max_connections 用于设定服务器的最大并发连接数，取值范围是 1 ~ 10 万，默认值是 151 。我们需要非常重视这个参数，因为它决定了 MySQL 允许多少个会话同时建立连接。几乎可以肯定，对于企业级应用来说，默认值是不够的的，我们通常把它设定为 500 ~ 1000 。需要注意，建立连接除了需要占用内存之外，还要求有计算能力，所以，不要把这个参数设置的太大。

max_connect_errors 这个参数的名字非常形象，它用于指定允许连接不成功的最大尝试次数。它的取值范围是 1 ~2^64 之间，默认值是 100 。需要注意的是，这个参数所表达的并不是 “ 单次连接最大的 Retry 次数 ” ，而是尝试连接总的失败次数上限。如果尝试连接的错误数量超过了参数所设定的值， MySQL 服务器则拒绝新的连接。所以，我们通常会把这个参数设置的比较大，建议 1 万以上

interactive_timeout 和 wait_timeout
我们大概率曾经遇到过这样的场景：打开的客户端或者程序在长时间没有被访问之后，需要重新与 MySQL 服务器建立连接。这其实是 MySQL 的一种优化保护机制，在超过了一定的时间始终没有使用之后，则认为当前的客户端已经不再使用了，断开连接回收资源。

interactive_timeout 和 wait_timeout 都与客户端会话的自动超时断开有关，其中 interactive_timeout 指的是服务器在关闭连接之前在一个交互连接上等待的秒数，默认值是 28800 ，即 8 个小时，建议将这个值调小。 wait_timeout则用于指定关闭非交互连接前等待的秒数，默认值仍是 8 个小时，可以根据业务场景适当的调大这个值。

max_binlog_size 和 expire_logs_days
不论是用什么语言、什么框架去编写应用程序，都一定会设计日志产出的方式和格式。其中， “ 方式 ” 中包含两个重要的点：
日志怎样滚动，一般会有两种方式：按照大小、按照时间。当然，也可以结合大小和时间。例如：单个日志文件超过 1GB 就生成一个新的日志文件
日志清理机制，一般会设定为清理 X 天之前的日志，即只保留 X 天的日志
expire_logs_days 的取值范围是 0 ~ 99 ，建议把它修改为 7 ~ 14 天； max_binlog_size 的取值范围是 4KB ~1GB ，默认为 1GB （ 1024 * 1024 * 1024 ），可以直接使用默认值。

也就是说，对于我们当前的存储引擎环境， buffer pool 空间还有剩余。如果发现 Innodb_buffer_pool_pages_free值很小或为 0 ，则说明 buffer pool 已经使用殆尽，需要增加 innodb_buffer_pool_size 的值

32 MySQL操作规范-

1. 建表时需要考虑的优化策略

1.2 保证列值是 NOT NULL 的

首先来说，为什么很多人会把列值设置为允许 NULL 呢？主要有两点原因：
数据表列默认就是 NULL 的，对于初级或者经验不足的同学没有显示指定 NOT NULL
NULL 列在插入时不需要指定数据，也不需要判断，比较方便简约
但是，为什么又需要保证列值是 NOT NULL 的呢？来看一看 MySQL 官方文档怎么说吧
它的意思是说： NULL 列需要额外的存储空间，且 MySQL 内部需要做特殊的处理。 MySQL 难以优化 NULL 列的查询，它会使索引、索引统计更加复杂。特别是对于 MyISAM 存储引擎的表，它可能会导致固定大小的索引变成可变大小的索引。

1.3 IP 地址存成 UNSIGNED INT
1.4 选择适当的索引字段，避免过度索引
1.6 99% 的表都应该是数字主键

你几乎（报表可以不定义）需要给每张表都定义主键，因为 MySQL 的存储引擎在很多情况下都需要依赖主键，例如：存储、分区等等。且主键可以唯一的确定一行记录，也减轻了数据查询的负担。
同时，这个主键应该是数字类型（ int 或 bigint ），而不是其他的类型，且给上 AUTO_INCREMENT 自增标识。这是因为：
对于自增主键，每次插入新的记录，记录就会顺序添加到当前索引节点的后续位置
对于非自增主键，每次插入的主键值近似随机，因此每次新纪录都要被插到现有索引页的中间某个位置，此时
MySQL 不得不为了将新记录插到合适位置而移动数据（造成节点的分裂和重组）
1.7 使用更小的数据类型
1.8 字符集编码需要统一

查询时需要考虑的优化策略
2.1 尽量避免在 SQL 中出现函数
2.2 慎用 IN 和 NOT IN
由于 IN 和 NOT IN 中定义的值是不确定的，所以， MySQL 不会对上述的两个查询使用索引。这里可以做的优化是，对于连续的数值，我们可以使用 BETWEEN 来代替 IN 。由于 BETWEEN 定义的是一个连续的区间，所以，可以使用到索引。如下所示 SELECT id, name, salary FROM worker WHERE salary BETWEEN 1 AND 3;
2.4 功能强大的 LIMIT
2.5 尽量避免在 WHERE 子句中对字段进行表达式操作
2.6 尽量避免在 WHERE 子句中对字段进行函数操作
2.7 尽量避免在 WHERE 子句中判断不等于
– 强制使用 salary_name_idx 索引（ salary_name_idx 需要存在）
SELECT id, name, salary FROM worker FORCE INDEX(salary_name_idx) WHERE salary >= @sal;

33如何优化数据导入？