干数据库这行的人，谁没被“把数据从一张表弄到另一张表”这事折磨过？看起来简单，不就是复制粘贴吗？可真上手了才发现，里面全是坑。表结构不一样怎么办？数据量太大跑不动怎么办？线上业务还在跑，复制数据会不会锁表？这些糟心事，我今天一次性给你捋清楚。
最直观的入门操作，就是INSERT INTO SELECT。这招适合表结构基本一致、数据量又不算太大的场景。写法也直白：。但这里有个隐藏的坑，你SELECT出来的数据类型和长度，必须和目标表完全兼容，否则数据库会毫不留情地给你报错。而且，如果源表数据是几百万行起步，这条语句跑起来能把事务日志撑爆，磁盘空间不够的直接就挂了。所以这招适合小打小闹，或者一次性初始化数据。
要是碰上表结构不一样，那就得用CREATE TABLE AS SELECT，也就是大家常说的CTAS。这招的精髓在于，它不光复制数据，还能顺手把表结构也建出来。你可以在SELECT里做各种转换，比如把字符串截断、把日期格式改掉、把多表JOIN的结果直接灌进一张新表。对于数据分析师来说，这简直是神器，几分钟就能拉出各种宽表。但要注意，CTAS默认不会复制索引、主键、外键这些约束，新表就是个“裸表”，后续还得自己补索引，否则查询慢到怀疑人生。
真正让老手头疼的，是那种跨数据库、甚至跨服务器的复制。这时候你就得掏出INSERT INTO ... SELECT加上外部数据源，或者用数据库自带的导入导出工具。比如MySQL的mysqldump、PostgreSQL的pgdump，还有SQL Server的BCP。这些工具的好处是能处理大数据量，而且支持断点续传、压缩传输。但坏处也明显，你得写一堆命令行参数，还要处理字符集、换行符这些乱七八糟的细节。有一次我帮客户迁移一个Oracle库，光处理中文乱码就折腾了三个小时，发现是NLSLANG环境变量没设对。
说到大数据量，就绕不开分批处理这个思路。你千万别指望一条SQL把一亿行数据一次性搬完，那纯粹是给自己找麻烦。正确的打开方式是，用主键ID或者时间戳做范围划分，比如每次只取ID在1到10万之间的记录，搬完这批再搬下一批。这样做的最大好处是，每批事务都很小，不会把日志撑爆，也不容易把源库的锁持有太久。而且万一某批失败了，你只要重新跑那一段就行，不用从头再来。这个思路在ETL工具里叫“增量抽取”，在手工操作里叫“切分窗口”，本质都一样。
还有一个容易被忽略的细节，就是锁和事务隔离级别。当你往目标表写数据时，数据库默认会加锁，如果源表也在被线上业务读写，那你复制数据时可能把源表的写操作给堵住。这时候你得考虑用READ UNCOMMITTED或者SNAPSHOT隔离级别，让SELECT查询不申请共享锁。另外，如果目标表已经存在大量数据，你还要考虑是否先TRUNCATE掉旧数据，还是用MERGE语句来按条件更新插入。MERGE这招很强大，但用不好也会踩坑，比如匹配条件写错了，会把不该更新的行全给改掉，连后悔药都没得吃。
说到工具，很多人喜欢用Navicat或者DBeaver这类图形化客户端，点几下按钮就把数据复制了。说实话，对于几十万行的小表，这些工具确实方便，而且自带进度条，能让你看到复制到哪了。但一旦数据量到了千万级，这些工具就开始拉胯了，要么内存溢出，要么网络断掉之后没有断点续传。我见过一个同事用Navicat复制一张五千万行的表，跑了两个小时直接卡死，还得回退到命令行工具重新来过。所以我的建议是，小数据量用图形化工具，大数据量老老实实用命令行。
再往深了说，如果你在云上，像AWS的DMS、阿里云的DTS这种托管迁移服务，其实更省心。它们支持不停机迁移，自动处理全量加增量，还能监控迁移进度。但缺点是要钱，而且配置起来也不简单，要设置源端连接、目标端连接、迁移任务、映射规则，一套下来没半天搞不定。但如果你是做企业级系统，数据是核心资产，那这点时间和钱还是值得花的。毕竟自己写脚本迁移，出错了排查起来更费劲。
送你几句实在话。第一，动手之前先看数据量，量力而行选方案。第二，复制之前先备份目标表，哪怕只是临时表，出问题能回滚。第三，跑完一定要做校验，比如对比行数、对比SUM值、抽查几条关键记录的字段内容。很多人复制完数据就直接上线，结果少搬了几万行都不知道，等业务出问题才后悔。数据迁移这事，从来不缺翻车的案例，缺的是提前把方案想周全的人。高效复制，从来不是指手速快，而是指每一步都稳、准、狠。
