【有奖话题讨论】如何优雅地使用MySQL存储海量数据？

阿文口

最优雅的就是换数据库。

东风玖哥

（1）在日常工作中，大家是如何进行MySQL优化的？请简单说说你的优化过程。
1. 首先得看数据库额设计是否贴切业务逻辑，不恰当的数据库逻辑设计往往优化也起不了多少作用。
2. 需要选择合适的数据库字段类型。
3. 选择合适的数据库引擎。譬如MyISAM、InnoDB、BDB、Memory、merge、archive、federated、cluster/NDB、csv、NlackHole等。一般情况下，我们使用MYISAM和InnoDB比较多，如果需要用到事务或外键的，选择InnoDB，否则使用MyISAM。

（2）随着MySQL中存储的数据越来越多，此时需要对MySQL中的数据进行拆分。各位是如何拆分MySQL中的数据的？
1. 使用mysqldump 把表逻辑倒出，然后再source 到其它地方
2. 使用xtrabackup 把表、或者库逻辑备份出，然后再recovery出一个实例
3. 使用MySQL自带的表空间转移（Transport）

（3）MySQL如何实现生产环境的灰度发布？
1. 接口以及网页，最简单粗暴的方法就是直接请求灰度相关的域名
2. 在不更换接口域名的前提下，在请求原有生产环境的接口上带上一个灰度的标记，例如Cookie，通过k8s的路由机制，对请求的数据进行处理，如果遇到带有灰度标记的Cookie，就把这个请求转发到灰度的k8s服务里面
3. 在不更换网页域名的前提下，在正常网页里面，每当用户刷新或者打开网页的时候，先判断此用户是否在灰度环境中，若在灰度环境中，强制加上灰度的标志（即Cookie），然后借由网页的机制进行301重定向，接着重复第2步的流程
4. 定时任务处理的时候加上用户灰度环境的判断，只对当前环境的数据进行处理
5. 消息队列，在发送消息队列的时候也需要对灰度环境进行判断，若是灰度环境的消息，则发送到灰度的队列里面，处理消息也同理
6. MySQL的binlog日志处理，由于灰度环境跟生产环境是公用一个数据库，此时这个日志信息处理只能跑一个，不能灰度跟生产环境同时跑，可以在代码中加上一个版本号，只有当灰度环境的版本号大于生产环境的，才在灰度环境中开启进程处理binlog日志

（4）本书是一本以实战为主的MySQL图书，但也不乏有对其背后原理的讲解。你觉得在实际工作中，有哪些地方需要更多、更深入的探讨和说明？
1. 需要探讨MySQL的5.x版本与6.x版本的区别
2. MySQL的事务隔离级别如何选择

王江玉

挺好，支持

aloki

（1）在日常工作中，大家是如何进行MySQL优化的？请简单说说你的优化过程。
对MySQL优化可以从如下几个方面进行：
·设计数据库时：数据库表、字段的设计，存储引擎
·利用好MySQL自身提供的功能，如索引等
·SQL语句的优化（收效甚微）
总之不要听信你看到的关于优化的“绝对真理”，而应该是在实际的业务场景下通过测试来验证你关于执行计划以及响应时间的假设。

（2）随着MySQL中存储的数据越来越多，此时需要对MySQL中的数据进行拆分。各位是如何拆分MySQL中的数据的？
某网站现在的数据量至多是5000万条，可以设计每张表容纳的数据量是500万条，也就是拆分成10张表。
那么如何判断某张表的数据是否容量已满呢?可以在程序段对于要新增数据的表，在插入前先做统计表记录数量的操作，当<500万条数据，就直接插入，当已经到达阀值，可以在程序段新创建数据库表(或者已经事先创建好)，再执行插入操作。
拆分的原则是设计表的时候需要确定此表按照什么样的规则进行分库分表。例如，当有新用户时，程序得确定将此用户信息添加到哪个表中;同理，当登录的时候我们得通过用户的账号找到数据库中对应的记录，所有的这些都需要按照某一规则进行。

（3）MySQL如何实现生产环境的灰度发布？
数据库变动部分场景无法进行灰度发布。比如，删除数据库字段，插入数据计算逻辑变动等

（4）本书是一本以实战为主的MySQL图书，但也不乏有对其背后原理的讲解。你觉得在实际工作中，有哪些地方需要更多、更深入的探讨和说明？
MySQL排错

ylky_2000

（1）在日常工作中，大家是如何进行MySQL优化的？请简单说说你的优化过程。
         1、EXPLAIN
做MySQL优化，我们要善用 EXPLAIN 查看SQL执行计划。重点关注
type列，连接类型。一个好的sql语句至少要达到range级别。杜绝出现all级别
key列，使用到的索引名。如果没有选择索引，值是NULL。可以采取强制索引方式
key_len列，索引长度
rows列，扫描行数。该值是个预估值
extra列，详细说明。注意常见的不太友好的值有：Using filesort, Using temporary
2、SQL语句中IN包含的值不应过多
MySQL对于IN做了相应的优化，即将IN中的常量全部存储在一个数组里面，而且这个数组是排好序的。但是如果数值较多，产生的消耗也是比较大的。再例如：select id from table_name where num in(1,2,3) 对于连续的数值，能用 between 就不要用 in 了；再或者使用连接来替换；
3、SELECT语句务必指明字段名称
SELECT *增加很多不必要的消耗（cpu、io、内存、网络带宽）；增加了使用覆盖索引的可能性；当表结构发生改变时，前断也需要更新。所以要求直接在select后面接上字段名。
4、当只需要一条数据的时候，使用limit 1
这是为了使EXPLAIN中type列达到const类型
5、如果排序字段没有用到索引，就尽量少排序
  6、如果限制条件中其他字段没有索引，尽量少用or
or两边的字段中，如果有一个不是索引字段，而其他条件也不是索引字段，会造成该查询不走索引的情况。很多时候使用 union all 或者是union(必要的时候)的方式来代替“or”会得到更好的效果
7、尽量用union all代替union
union和union all的差异主要是前者需要将结果集合并后再进行唯一性过滤操作，这就会涉及到排序，增加大量的CPU运算，加大资源消耗及延迟。当然，union all的前提条件是两个结果集没有重复数据。


（2）随着MySQL中存储的数据越来越多，此时需要对MySQL中的数据进行拆分。各位是如何拆分MySQL中的数据的？
       数据表的水平与垂直拆分：
垂直拆分：按字段功能主次拆分，比如最常见的商品表、商品图片表、商品详细信息…表与表之间的结构不同
水平拆分：同数据库的水平拆分原理一样主要是将数据进行拆分保存到不同的表当中，这些表的结构完全相同。、

使用用垂直拆分要主要看系统是否适合这种拆分方式，如系统可分为用户系统，商品系统、订单系统等这些业务比较明确的比较适合使用垂直拆分，垂直拆分能很好分散数据库压力。业务模块不清晰，模块耦合度较高的系统并不适合垂直拆分。垂直拆分并不能彻底解决所有的压力问题，例如有一张8000w的订单表而且订单随着时间还在一直增加，操作起这张订单表压力依然很大，如我们需要在这个表中增加(insert)一条新的数据，insert完毕后，数据库会针对这张表重新建立索引，8000w行数据建立索引的系统开销还是不容忽视的，这类情况就可以使用到水平拆分了，可以将表分成100个table，table_001一直到table_100，8000w数据平均分下来就是80万的数据（经过实际测试mysql数据量达到400w的时候性能明显降低，故而应将单个mysql的数据量控制在300W以内），这时候我们向一张只有80w行数据的table中insert数据后建立索引的时间就会呈数量级的下降，极大了提高了DB的运行时效率，提高了DB的并发量，这种拆分就是水平（横向）拆分
（3）MySQL如何实现生产环境的灰度发布？
     我们不在生产环境搞，一般会模拟一个跟生产环境一样的基础软环境（规模和硬件低很多）进行发布测试。
（4）本书是一本以实战为主的MySQL图书，但也不乏有对其背后原理的讲解。你觉得在实际工作中，有哪些地方需要更多、更深入的探讨和说明？
         很优秀了。谢谢。。。

devil3380

1.        SQL 优化
sql 优化分析
索引优化
2.        优化数据库对象
优化表的数据类型
表拆分（水平、垂直）
反范式
使用中间表
3.        优化 mysql server
mysql 内存管理优化
log 机制及优化
调整 mysql 并发参数
4.        应用优化
数据库连接池
使用缓存减少压力
负载均衡建立集群
主主同步、主从复制

help01

（1）在日常工作中，大家是如何进行MySQL优化的？请简单说说你的优化过程。
  MYSQL性能优化包括查询速度优化，更新速度优化，mysql服务器优化等等。这要求我们一方面找出系统的瓶颈，提高mysql数据库整体的性能，另外一个方面需要合理的结构设计和参数调整，以提高用户操作响应的速度。同时还要尽可能节省系统资源，以便系统可以提供更大负荷的服务。mysql数据库优化是多方面的，原则是减少系统的瓶颈，减少资源的占用，增加系统反应的速度。比如选取最适用的字段属性，将表中字段的宽度设得尽可能小；在可能的情况下，应该尽量把字段设置为NOT NULL；使用连接来代替子查询，使用联合来代替手动创建的临时表，优化查询语句等等。

（2）随着MySQL中存储的数据越来越多，此时需要对MySQL中的数据进行拆分。各位是如何拆分MySQL中的数据的？
  a.使用mysqldump 把表逻辑倒出，然后再source 到其它地方；
  b.使用xtrabackup 把表、或者库逻辑备份出，然后再recovery出一个实例;
  c.使用MySQL自带的表空间转移。

（3）MySQL如何实现生产环境的灰度发布？
  a.请求灰度相关的域名；
  b.在不更换接口域名的前提下，在请求原有生产环境的接口带上一个灰度标记（例如Cookie），如果遇到带有灰度标记的Cookie就把请求转发到灰度的服务进行处理；
  c.每当用户刷新或者打开网页的时候，先判断此用户是否在灰度环境中，若在灰度环境中，强制加上灰度的标志（即Cookie），然后借由网页的机制进行301重定向，接着重复流程b；
  d.定时任务处理的时候加上用户灰度环境的判断，只对当前环境的数据进行处理;
  e.在发送消息队列的时候也需要对灰度环境进行判断，若是灰度环境的消息，则发送到灰度的队列里面，处理消息也同理;
  f.由于灰度环境跟生产环境共用一个数据库，此时Mysql的binlog日志信息处理只能跑一个，可以在代码中加上一个版本号，只有当灰度环境的版本号大于生产环境的，才在灰度环境中开启进程处理binlog日志；
  g.app升级。app端请求版本接口的时候无需带上Cookie，只需要带上用户的ID，接口这边判断用户是否在灰度环境中，是的话则返回灰度环境下最新的版本号；
  h.小程序升级，由于小程序升级是在网页段进行升级的，判断用户是否在灰度环境中，是的话用灰度环境的小程序模板ID等信息提交小程序审核；
  i.做一套可以随时将用户拉入以及剔除灰度名单的功能。
  
  (4）本书是一本以实战为主的MySQL图书，但也不乏有对其背后原理的讲解。你觉得在实际工作中，有哪些地方需要更多、更深入的探讨和说明？
  安全、锁、索引、隔离级别、备份、日志等。