mysql>
alter
table
test
add
column
birth
date
Query
OK,
0
rows
affected
(0.36
sec)
Records:
0
Duplicates:
0
Warnings:
0
查询一下数据，看看结果：
mysql>
select
*
from
test
+------+--------+----------------------------------+------------+-------+
|
t_id
|
t_name
|
t_password
|
t_birth
|
birth
|
+------+--------+----------------------------------+------------+-------+
|
1
|
name1
|
12345678901234567890123456789012
|
NULL
|
NULL
|
|
2
|
name2
|
12345678901234567890123456789012
|
2013-01-01
|
NULL
|
+------+--------+----------------------------------+------------+-------+
2
rows
in
set
(0.00
sec)
从上面结果可以看出，插入的birth字段，默认值为空。我们再来试一下，添加一个birth1字段，设置它不允许为空。
mysql>
alter
table
test
add
column
birth1
date
not
null
Query
OK,
0
rows
affected
(0.16
sec)
Records:
0
Duplicates:
0
Warnings:
0
居然执行成功了！？意外了！我原来以为，这个语句不会成功的，因为我没有给他指定一个默认值。我们来看看数据：
mysql>
select
*
from
test
+------+--------+----------------------------------+------------+-------+------------+
|
t_id
|
t_name
|
t_password
|
t_birth
|
birth
|
birth1
|
+------+--------+----------------------------------+------------+-------+------------+
|
1
|
name1
|
12345678901234567890123456789012
|
NULL
|
NULL
|
0000-00-00
|
|
2
|
name2
|
12345678901234567890123456789012
|
2013-01-01
|
NULL
|
0000-00-00
|
+------+--------+----------------------------------+------------+-------+------------+
2
rows
in
set
(0.00
sec)
哦，明白了，系统自动将date类型的值，设置了一个默认值：0000-00-00。下面我来直接指定一个默认值看看：
mysql>
alter
table
test
add
column
birth2
date
default
'2013-1-1'
Query
OK,
0
rows
affected
(0.28
sec)
Records:
0
Duplicates:
0
Warnings:
0
mysql>
select
*
from
test
+------+--------+----------------------------------+------------+-------+------------+------------+
|
t_id
|
t_name
|
t_password
|
t_birth
|
birth
|
birth1
|
birth2
|
+------+--------+----------------------------------+------------+-------+------------+------------+
|
1
|
name1
|
12345678901234567890123456789012
|
NULL
|
NULL
|
0000-00-00
|
2013-01-01
|
|
2
|
name2
|
12345678901234567890123456789012
|
2013-01-01
|
NULL
|
0000-00-00
|
2013-01-01
|
+------+--------+----------------------------------+------------+-------+------------+------------+
2
rows
in
set
(0.00
sec)
看到没，将增加的birth2字段，就有一个默认值了，而且这个默认值是我们手工指定的。
关于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 慢的超出想像， 会明白这里是有问题的
10. 新手， 请在本地练习之后， 再实际 *** 作； 可以多 *** 作几次， 写一个脚本，服务器上直接执行脚本.
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）