MySQL版本升级注意事项

1、升级是一件风险极高的任务，备份重于一切。

2、了解新版本变更的信息（哪些不再兼容，不再支持哪些功能）。

1、确认新版本是否有重大变更

2、注意 SQL mode 的变化，比如：MySQL5.7发生了SQL mode的变化，对不再支持的SQL mode，部分SQL会跑不通，可以清空SQL mode，跑完之后在设置SQL mode。

3、升级成功后，确认业务SQL是否可以跑通，程序层是否都正常。

4、在升级完成之后，一定要在测试时使用和线上版本相同的程序，测试是否存在问题。

5、存储引擎的变化，比如：在未来的5.8版本，不再支持myisam 引擎。

6、注意字符集的乱码问题。

7、升级过程中多次启动建议加上 --skip-grant-tables和--skip-networking 参数，来保证没有任何的应用连接，让升级过程更加安全。

数据库作为应用开发中必不缺少的基础设施，其性能直接影响应用的整体运行速度。MySQL是目前最广泛使用的关系型数据库之一，对于开发人员写出性能良好的SQL是必备的基本技能之一。下面简单描述下编写SQL的注意事项。

编写高质量的SQL需要从以下几个方面注意，基本原则、表字段注意事项、索引使用注意事项、SQL注意事项。

基本原则

一、尽量不要在数据库里做运算。如果遇到运算尽可能在应用程序层进行计算。

二、控制数据库表数量、控制单表数据量、控制表的字段数。建议单库不要超过四百张表，建议单表字段不要超过五十个，建议单表的数据量不要超过一千万。

三、不要编写大SQL、不要使用大事务。SQL尽量写的简单点拒绝编写大SQL，可以将大SQL拆分成多个小SQL，在应用层聚合。大事务拆分成多个小事务，快速提交。

表字段注意事项

一、选择合适数值字段类型。能用小字段类型的就用小字段类型，如tinyint就比int(1)在表示小数据时合适。

二、能用数字表示就不要用字符。如可以用无符号INT存储IP而不是字符串表示。

三、避免使用NULL字段。原因NULL字段查询优化难，含NULL复合索引失效。

四、少用或拆分TEXT/BLOB字段。字段太大需要更多的空间，性能低下，如需使用拆分到单独表。

五、不要在表字段中存储图片。

索引使用注意事项

一、合理添加索引。索引添加太多会影响更新速度。能够使用复合索引的避免加多个单独索引。

二、字符字段建立前缀索引。

三、不在索引列做运算。索引列做运算会导致索引失效。

四、尽量不使用外建。

SQL类注意事项

一、 SQL语句尽可能简单。大SQL拆分成多个小SQL。

二、事务编写尽量短小。事务即开即用用完立即关闭。

三、尽量不要使用select *。只取需要的列。

四、改写OR为IN或者改写为UNION *** 作。OR在数据量大的时候性能低于IN。

五、避免NOT、!=、>、NOT IN、NOT EXISTS、NOT LIKE等查询。

六、避免%前缀模糊查询。

七、能用UNION ALL不要用UNION。

八、GROUP BY中去除排序。自带排序。

九、同类型的字段做比较。字符类和字符类比较，数值类和数值类比较，不要混在一起比较。

十、尽量单表查询，尽量不要多表关联查询。多表关联查询可以拆分成单表查询在应用程序中聚合数据。

十一、复合索引的多列注意最左原则。

上述注意事项能避免很多性能低下的SQL，希望在开发过程中能引起注意。

1.最左前缀匹配原则，非常重要的原则，mysql会一直向右匹配直到遇到范围查询(>、<、between、like)就停止匹配，比如a = 1 and b = 2 and c >3 and d = 4 如果建立(a,b,c,d)顺序的索引，d是用不到索引的，如果建立(a,b,d,c)的索引则都可以用到，a,b,d的顺序可以任意调整。

2.=和in可以乱序，比如a = 1 and b = 2 and c = 3 建立(a,b,c)索引可以任意顺序，mysql的查询优化器会帮你优化成索引可以识别的形式。

3.尽量选择区分度高的列作为索引，区分度的公式是count(distinct col)/count(*)，表示字段不重复的比例，比例越大我们扫描的记录数越少，唯一键的区分度是1，而一些状态、性别字段可能在大数据面前区分度就是0，那可能有人会问，这个比例有什么经验值吗？使用场景不同，这个值也很难确定，一般需要join的字段我们都要求是0.1以上，即平均1条扫描10条记录。

4.索引列不能参与计算，保持列“干净”，比如from_unixtime(create_time) = ’2014-05-29’就不能使用到索引，原因很简单，b+树中存的都是数据表中的字段值，但进行检索时，需要把所有元素都应用函数才能比较，显然成本太大。所以语句应该写成create_time = unix_timestamp(’2014-05-29’)。

5.尽量的扩展索引，不要新建索引。比如表中已经有a的索引，现在要加(a,b)的索引，那么只需要修改原来的索引即可。

1."一个顶三个"。建了一个(a,b,c)的复合索引，那么实际等于建了(a),(a,b),(a,b,c)三个索引，因为每多一个索引，都会增加写 *** 作的开销和磁盘空间的开销。对于大量数据的表，这可是不小的开销！

2.覆盖索引。同样的有复合索引（a,b,c），如果有如下的sql: select a,b,c from table where a=1 and b = 1。那么MySQL可以直接通过遍历索引取得数据，而无需回表，这减少了很多的随机io *** 作。减少io *** 作，特别的随机io其实是dba主要的优化策略。所以，在真正的实际应用中，覆盖索引是主要的提升性能的优化手段之一

3.索引列越多，通过索引筛选出的数据越少。有1000W条数据的表，有如下sql:select * from table where a = 1 and b =2 and c = 3,假设假设每个条件可以筛选出10%的数据，如果只有单值索引，那么通过该索引能筛选出1000W*10%=100w 条数据，然后再回表从100w条数据中找到符合b=2 and c= 3的数据，然后再排序，再分页；如果是复合索引，通过索引筛选出1000w *10% *10% *10%=1w，然后再排序、分页，哪个更高效，一眼便知

---