如何在mysql大数据量表中增加一个字段

1. 能不加字段就不要加， 能不修改字段就不要修改， 能不删除字段就不要删除， 等等为什么要删除字段呢？ 如果没事，不要蛋疼的找事。 实际上，我们那次更新失败后， 我们并没有增加那个字段， 然后我们一直运行到今天， 但是后来还是增加了其他字段

2. 增加字段的情况下， 如果可以通过增加一个新的表来增加这个字段， 那么就增加一个新的表， 通过cache 或 程序来实现join 的效果

3. 如果能停机， 并且停机的时间在你容忍范围之内， 数据备份之后停机来做。 如果是主从备份，做这样大的 *** 作的时候，停掉主从备份， 万一你挂了， 备份数据库可以救你。 等到一切安全了， 重启主从备份；

4. 如果上面都不行， 这个字段还是要改，要加， 需要用到下面的方法， 也是扇贝网正在使用的方法；

修改大数据表的方法：

1. 被修改的表 Table A 需要有一个记录时间戳的字段， 这个时间戳就是每次数据更新，都会更新的字段， 这个字段需要有索引，在django里可以使用 auto_now=True

2. 创建一个新的临时表 Table B， 不是tmp_table, 是一个新的表，但是是临时使用的。 这个表和要修改的表拥有一模一样的数据结构， 加上你要修改的部分， 比如增加的字段；

3. 记录下Table A 的索引

4. 删除 Table B 的全部索引

5. 把Table A 的数据全部复制到Table B, 是不是执行 INSERT INTO B(field1, field2) SELECT field1, field2 FROM A？ 当然不是， 这么做不还是锁死了Table A 么， 这里的迁移就是一个需要细分的地方，需要写一个脚本， 让程序每次读取比如5000条数据出来， 插入到Table B里面， 因为Table B 是没有索引的， 所以要当心不要使用多进程来做； 如果是多进程， 要确保插入到B的时候是不会有重复数据的； 如果是1000万的数据，每次5000条， 假设这个 *** 作需要500ms， 那么 2000*200ms = 16 分钟。 这只是一个估值， 具体情况和服务器当时的情况有关， 不好细说。 另外， 我们要记录这个迁移开始的时间点，记为t1

6. 那么这个时候Table A 的数据是不是都进入了Table B 呢， 应当说差不多大部分都进入了， 但5中说， 这大概需要16分钟， 这么长的时间里， 可能有新的数据进入了， 也有可能已有的数据发生了更新， 所以我们要把Table A 中在t1 之后发生变化的数据查找出来， 然后更新到Table B 中， 我们的做法是：

记录这个 *** 作对应的时间点 t2

BEGIN

DELETE FROM B WHERE updated_time >t1

INSERT INTO B(field1, field2) SELECT field1, field2 FROM A WHERE updated_time >t1

COMMIT

7. 现在A 和 B 差不多该同步了吧？ 差不多了， 但是6 执行完之后， A仍然在写， 子子孙孙无穷尽也 ... , 但这个时候 A 和 B 的差异已经非常非常小了， 所以在下一步，我们在一个transaction 里执行下面的 *** 作：

BEGIN

DELETE FROM B WHERE updated_time >t2

INSERT INTO B(field1, field2) SELECT field1, field2 FROM A WHERE updated_time >t2

ALTER TABLE A RENAME TO C

ALTER TABLE B RENAME TO A

COMMIT

8. Done

PS: 如果A表没有时间戳， 实际上没有先见之明的人大概不会想到要预留一个时间戳的字段， 那么几乎是没有办法快速比较两个表的差异的， 这个时候我选择的做法就是放弃修改的数据， 只管新的数据了， 所以只要把t1， t2 换成id 就可以了， 这样delete 语句也省略了， 因为没啥好delete的；

千万不要想着根据ID 来JOIN 然后更新B表的字段来补齐新的数据， 如果能把两个千万级别的表JOIN起来， 内存有多大呢？

9. 上面的解决方案是我们第二次尝试之后犯下了一个巨大的错误，这个错误导致网站瘫痪了大概20分钟， 如果你和我一样没有发现问题，那么这就是悲剧的地方。 问题就在于我是根据上面的PS来 *** 作的， 然后B就华丽地变成了A. B 表至今身上是没有索引的， 立即悲剧。 所以应当在第5步之后按照A的索引为B建立索引， 待索引全部好了之后， 再继续6。 如果不是走PS这条路， 而是有时间戳的字段的话， 在6的时候会发现这个问题， 因为那条Delete 慢的超出想像， 会明白这里是有问题的

ID已经设为主键了

200万的表跟4万的表，除非你系统的硬盘、内存、CPU配置特低，否则，效率上不至于你说的那么慢的（我普通的台式机CPU为1.5G的都不至于那么慢）

肯定有优化的余地，hi我吧

提问：如何设计或优化千万级别的大表？此外无其他信息，个人觉得这个话题有点范，就只好简单说下该如何做，对于一个存储设计，必须考虑业务特点，收集的信息如下：

1.数据的容量：1-3年内会大概多少条数据，每条数据大概多少字节；

2.数据项：是否有大字段，那些字段的值是否经常被更新；

3.数据查询SQL条件：哪些数据项的列名称经常出现在WHERE、GROUP BY、ORDER BY子句中等；

4.数据更新类SQL条件：有多少列经常出现UPDATE或DELETE 的WHERE子句中；

5.SQL量的统计比，如：SELECT：UPDATE+DELETE：INSERT=多少？

6.预计大表及相关联的SQL，每天总的执行量在何数量级？

7.表中的数据：更新为主的业务 还是 查询为主的业务

8.打算采用什么数据库物理服务器，以及数据库服务器架构？

9.并发如何？

10.存储引擎选择InnoDB还是MyISAM？

大致明白以上10个问题，至于如何设计此类的大表，应该什么都清楚了！

至于优化若是指创建好的表，不能变动表结构的话，那建议InnoDB引擎，多利用点内存，减轻磁盘IO负载，因为IO往往是数据库服务器的瓶颈。

另外对优化索引结构去解决性能问题的话，建议优先考虑修改类SQL语句，使他们更快些，不得已只靠索引组织结构的方式，当然此话前提是， 索引已经创建的非常好，若是读为主，可以考虑打开query_cache， 以及调整一些参数值：sort_buffer_size,read_buffer_size,read_rnd_buffer_size,join_buffer_siz。

更多信息参见：

MySQL数据库服务器端核心参数详解和推荐配置

不纸上谈兵，说一下我的思路以及我的解决，抛砖引玉了

我最近正在解决这个问题

我现在的公司有三张表，是5亿的数据，每天张表每天的增量是100w

每张表大概在10个columns左右

下面是我做的测试和对比

1.首先看engine,在大数据量情况下，在没有做分区的情况下

mysiam比innodb在只读的情况下，效率要高13％左右

2.在做了partition之后，你可以去读一下mysql的官方文档，其实对于partition，专门是对myisam做的优化，对于innodb，所有的数据是存在ibdata里面的，所以即使你可以看到schema变了，其实没有本质的变化

在分区出于同一个physical disk下面的情况下，提升大概只有1％

在分区在不同的physical disk下，我分到了三个不同的disks下，提升大概在3％，其实所谓的吞吐量，由很多因素决定的，比如你的explain parition时候可以看到，record在那一个分区，如果每个分区都有，其实本质上没有解决读的问题，这样只会提升写的效率。

另外一个问题在于，分区，你怎么分，如果一张表，有三个column都是经常被用于做查询条件的，其实是一件很悲惨的事情，因为你没有办法对所有的sql做针对性的分区，如果你只是如mysql官方文档上说的，只对时间做一个分区，而且你也只用时间查询的话，恭喜你

3.表主要用来读还是写，其实这个问题是不充分的，应该这样问，你在写入的时候，同时并发的查询多么？我的问题还比较简单，因为mongodb的 shredding支持不能，在crush之后，还是回到mysql，所以在通常情况下，9am－9pm，写入的情况很多，这个时候我会做一个 view，view是基于最近被插入或者经常被查询的，通过做view来分离读取，就是说写是在table上的，读在进行逻辑判断前是在view上 *** 作的

4做一些archive table，比如先对这些大表做很多已有的统计分析，然后通过已有的分析＋增量来解决

5如果你用mysiam，还有一个问题你要注意，如果你的.configure的时候，加了一个max index length参数的时候，当你的record数大于制定长度的时候，这个index会被disable

---