莫道君行早，更有早行人。
因为业务增长，原有的unsigned int已经不够使用，需要升级到unsigned bigint。
MYSQL整数支持的范围：https://dev.mysql.com/doc/refman/5.7/en/integer-types.html
| Type | Storage | Minimum Value | Maximum Value |
|---|---|---|---|
| (Bytes) | (Signed/Unsigned) | (Signed/Unsigned) | |
TINYINT |
1 | -128 |
127 |
0 |
255 |
||
SMALLINT |
2 | -32768 |
32767 |
0 |
65535 |
||
MEDIUMINT |
3 | -8388608 |
8388607 |
0 |
16777215 |
||
INT |
4 | -2147483648 |
2147483647 |
0 |
4294967295 |
||
BIGINT |
8 | -9223372036854775808 |
9223372036854775807 |
0 |
18446744073709551615 |
可以看到bigint支持的数量级非常大。虽然mysql字段类型调整了，但是我们的开发语言是否支持呢？
null是一个让人头疼的问题，比如java中的NullPointerException。为了避免猝不及防的空指针，需要小心翼翼地各种if判断，麻烦又臃肿.
为此有很多的开源包都有诸多处理
common lang3的StringUtils.isBlank(); CollectionUtils.isEmpty();
guava的Optional
甚至java8也引入了Optional来避免这一问题（和guava的大同小异，用法稍有一点点变化)
(a) 创建不规范 null是创建数据表时候默认的，一些mysql客户端的自动生成表语句里面可能也没有not null的指定。
(b) 错误认识 会有人觉得not null需要更多的空间
(c) 图省事 null在开发中不用判断插入数据，写sql更方便
……
Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Expression #1 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'db.table.id' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by
该问题是因为MySQL Server 默认开启了 sql_mode=only_full_group_by 模式，此模式要求 group by 字段必须出现在查询项中（select），否则就会报出该错误。解决的方式也很简单见（5），借着这个异常问题，借机在本文就来学习一下，MySQL 5.7 中的 sql_mode。
MySQL服务器可以在不同的SQL模式下运行，并且可以针对不同的客户端以不同的方式应用这些模式，具体取决于sql_mode系统变量的值。可以设置全局SQL模式以匹配站点服务器的操作要求，每个应用程序也可以设置会话级别的SQL模式来满足自己的需求。
sql_mode 模式会影响MYSQL语法及执行数据的验证检查。这使得在不同环境中使用MySQL以及将MySQL与其他数据库服务器一起使用变得更加容易。
查询全局sql_mode
SELECT @@GLOBAL.sql_mode;
查询当前会话sql_mode
SELECT @@SESSION.sql_mode;
ONLY_FULL_GROUP_BY, STRICT_TRANS_TABLES, NO_ZERO_IN_DATE, NO_ZERO_DATE, ERROR_FOR_DIVISION_BY_ZERO, NO_AUTO_CREATE_USER, NO_ENGINE_SUBSTITUTION
MySQL 5.7.5 中默认SQL模式添加了 ONLY_FULL_GROUP_BY和STRICT_TRANS_TABLES
MySQL 5.7.7 中默认SQL模式添加了 NO_AUTO_CREATE_USER
MySQL 5.7.8 中默认SQL模式添加了 ERROR_FOR_DIVISION_BY_ZERO，NO_ZERO_DATE 和 NO_ZERO_IN_DATE
一、事务的基本要素（ACID）
1、原子性（Atomicity）：事务开始后所有操作，要么全部做完，要么全部不做，不可能停滞在中间环节。事务执行过程中出错，会回滚到事务开始前的状态，所有的操作就像没有发生一样。也就是说事务是一个不可分割的整体，就像化学中学过的原子，是物质构成的基本单位。
2、一致性（Consistency）：事务开始前和结束后，数据库的完整性约束没有被破坏 。比如A向B转账，不可能A扣了钱，B却没收到。
3、隔离性（Isolation）：同一时间，只允许一个事务请求同一数据，不同的事务之间彼此没有任何干扰。比如A正在从一张银行卡中取钱，在A取钱的过程结束前，B不能向这张卡转账。
4、持久性（Durability）：事务完成后，事务对数据库的所有更新将被保存到数据库，不能回滚。
二、事务的并发问题 ……
三、MySQL事务隔离级别 ……
分布式事务通常采用2PC协议，全称Two Phase Commitment Protocol。该协议主要为了解决在分布式数据库场景下，所有节点间数据一致性的问题。在分布式事务环境下，事务的提交会变得相对比较复杂，因为多个节点的存在，可能存在部分节点提交失败的情况，即事务的ACID特性需要在各个数据库实例中保证。总而言之，在分布式提交时，只要发生一个节点提交失败，则所有的节点都不能提交，只有当所有节点都能提交时，整个分布式事务才允许被提交。
分布式事务通过2PC协议将提交分成两个阶段：
prepare；
commit/rollback
第一阶段的prepare只是用来询问每个节点事务是否能提交，只有当得到所有节点的“许可”的情况下，第二阶段的commit才能进行，否则就rollback。需要注意的是：prepare成功的事务，则必须全部提交。
本篇文章是对MySQL中优化sql语句查询常用的30种方法进行了详细的分析介绍，需要的朋友参考下。
1.对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。
2.应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。
3.应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：
select id from t where num is null
可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：
select id from t where num=0
...
在工作中，我们用于捕捉性能问题最常用的就是打开慢查询，定位执行效率差的SQL，那么当我们定位到一个SQL以后还不算完事，我们还需要知道该SQL的执行计划，比如是全表扫描，还是索引扫描，这些都需要通过EXPLAIN去完成。EXPLAIN命令是查看优化器如何决定执行查询的主要方法。可以帮助我们深入了解MySQL的基于开销的优化器，还可以获得很多可能被优化器考虑到的访问策略的细节，以及当运行SQL语句时哪种策略预计会被优化器采用。需要注意的是，生成的QEP并不确定，它可能会根据很多因素发生改变。MySQL不会将一个QEP和某个给定查询绑定，QEP将由SQL语句每次执行时的实际情况确定，即便使用存储过程也是如此。尽管在存储过程中SQL语句都是预先解析过的，但QEP仍然会在每次调用存储过程的时候才被确定。