数据库选型这件事，说实话，做过几年项目的人都明白：没有“最好”的数据库，只有“当前场景下最合适”的数据库。我见过不少团队，一上来就奔着最流行的MySQL去，结果业务里全是复杂报表查询，跑个聚合要几秒钟；也见过因为图方便选了SQLite做服务端存储，结果多人并发写入时频繁遇到“database is locked”的。这些坑的本质，往往不是某个数据库不行，而是没想清楚自己到底需要什么。这篇东西我打算按场景把常用数据库盘一遍，包括MySQL、PostgreSQL、Oracle这些关系型老将，SQLite这种轻量级选手，再加上达梦、人大金仓这些近几年项目里越来越多见的国产数据库，以及Redis、MongoDB、向量数据库这些非关系型产品。无论你是刚做数据库课程设计的学生，还是在纠结生产环境选型的开发者，又或者是想搞清楚“某某数据库到底适不适合我这个业务”的项目负责人，都可以照着这篇思路去对号入座。
1. 数据库分类逻辑先理清，选型才不容易跑偏
1.1 OLTP还是OLAP，先分清自己是哪种负载
很多人选数据库的时候第一反应是“谁名气大选谁”，但其实第一个要判断的是业务到底属于联机事务处理还是联机分析处理。用大白话讲，OLTP就是日常业务系统里那种频繁的增删改查，像点外卖下单、用户登录记录、库存扣减，每次操作的数据量很小，但请求量极高，对事务一致性要求很严格。OLAP则相反，它是拿一整套数据做统计分析，比如“上个月所有门店的销售额按品类汇总”，单次查询要扫几百万行甚至上亿行，要求的是吞吐和聚合能力，而不是高频小事务。
这个差别直接决定了数据库的类型。MySQL、PostgreSQL、Oracle这类关系型数据库主要是OLTP场景，也能勉强做轻量分析，但数据量一旦上去，一个复杂GROUP BY就能把CPU打满。我见过真实案例，报表系统直接在业务库上跑统计，每周一早上主库CPU直接飙到99%，后面不得不把分析请求引流到专门的OLAP数据库。所以选型时第一个问题不是“用MySQL还是Doris”，而是“我正在解决的业务，痛点到底是多少并发小事务，还是海量数据的大查询”。
1.2 关系型和非关系型，本质是“关系”和“事务”谁更重要
关系型数据库这个“关系”，指的是表和表之间可以通过外键、JOIN去维护数据之间的关联。比如订单表关联用户表、订单明细表关联商品表，整个模型就像一张精心设计的Excel网状表格。它的立身之本是ACID事务，也就是要么全部成功，要么全部回滚，绝不会出现“钱扣了但订单没生成”这种中间态。这种一致性价值，在金融、电商、订单这类系统里是无可替代的。
非关系型数据库并不是一个东西，而是很多分支：Redis这类键值数据库像一个大号共享字典，适合缓存和临时数据；MongoDB这类文档数据库存的是JSON结构，适合字段经常变化的业务；图数据库专门处理人和人、节点和节点之间的关系；列式存储数据库则天生为分析而生。它们大多数都放松了事务约束，换来的是性能、扩展性或者灵活度。举个例子，一个内容社区的产品信息，不同内容类型字段差异很大，用关系型你得建一大堆可空字段或子表，但在MongoDB里直接存文档就行。反过来，如果你把订单金额这种强一致数据放进Redis当持久化存储，那崩溃丢数据的风险会让你睡不着。
1.3 部署形态和运维能力，也会卡死很多选择
数据库本身的能力是一回事，能不能驾驭它又是另一回事。单文件型数据库，比如SQLite，整个库就是一个文件，移动App、嵌入式设备、本地工具都爱用，但你把它架到服务器上让几十个进程同时写，很快就会遇到锁竞争。传统单机数据库，比如MySQL、PostgreSQL，一张表的数据量在一个可控范围内都表现不错，可一旦你要扩展到主从复制或者分库分表，数据一致性、故障切换的复杂度会成倍增加。
选择分布式数据库或云数据库之前，先要确认团队有没有相应运维能力。Oracle这种老牌商业库功能很全，但你要懂表空间、归档模式、冷备热备；达梦、人大金仓这样的国产库，功能特性越来越接近Oracle和PostgreSQL，但学习资料相对少，遇到问题要耐心翻官方文档。对于中小团队，如果业务规模还没到瓶颈，优先选自己熟悉、社区活跃度高的东西，比追新更重要。工具选得再花哨，最终是要有人能把它稳定跑上三年的。
2. 关系型数据库怎么挑：MySQL、PostgreSQL、SQL Server、Oracle逐个说
2.1 MySQL：大多数业务系统的默认答案
MySQL能成为国内使用率最高的开源关系型数据库，真不是靠营销。它上手难度低，三分钟装完就能建库建表，InnoDB存储引擎默认支持事务和行级锁，5.7到8.0的版本升级后功能已经相当能打，utf8mb4字符集妥善解决了emoji存储问题。社区资料极其丰富，哪怕你遇到很冷门的报错，基本搜索一下就能找到别人踩坑的帖子。因此互联网业务、创业公司后台、后台管理系统、内容管理系统，只要不是特别非主流的需求，闭眼选MySQL基本不会出大错。
安装和日常使用里面有若干细节值得记一下。生产环境建议直接选8.0以上版本，5.7已经停止维护更新很久了，新项目没必要再用老版本。安装时字符集要选utf8mb4，排序规则选utf8mb4_0900_ai_ci或utf8mb4_general_ci都行，千万不要再设成老版utf8，否则存不了生僻字和emoji，后面改字符集还容易锁表。表结构设计上，如果明确要加唯一约束，先清理重复数据再建约束，否则会直接报“Duplicate entry”，这点我在后面故障排查部分再展开。常用备份命令是mysqldump，小数据量完全够用，大库则建议用XtraBackup之类物理备份工具，减少锁表时间。
2.2 PostgreSQL：功能全面，复杂业务里的六边形战士
PostgreSQL在很多老MySQL用户嘴里是“用了就回不去”的数据库，这句话有些夸张，但它确实在功能密度上有优势。它能存JSON/JSONB，可以直接在数据库里做JSON字段的查询和索引；具备窗口函数、CTE、递归查询等高级SQL能力，分析类需求不用额外接一套平台就能支撑；扩展生态还有PostGIS做地理空间数据，适合LBS类应用；而它对数据完整性、约束、外键、触发器的处理也相当严格。如果你的业务里有复杂的报表查询、地理信息、全文检索，或者数据完整性要求极高，PostgreSQL就比MySQL更顺手。
那MySQL和PostgreSQL到底怎么选？我给一个标准参考：如果你的团队本身只熟悉MySQL、业务是标准的电商或CMS，继续用MySQL，技术风险最低；如果你是做GIS、金融对账、复杂报表系统，或者想用一个“什么都能干”的库来降低后端复杂度，可以考虑PostgreSQL。需要注意的是，PostgreSQL的默认事务隔离级别、部分SQL写法与MySQL有差异，从MySQL迁过来时那些依赖ON DUPLICATE KEY UPDATE之类的语句要改成ON CONFLICT DO UPDATE语法，不是简单照搬就能跑通的。
2.3 SQL Server：Windows技术栈里的老搭档
SQL Server在国内虽然不像MySQL那样遍地都是，但在很多企业级项目里依然稳坐钓鱼台，尤其是那些基于.NET/Windows Server的团队，SQL Server和Windows环境配合得最舒服。它自带SQL Server Management Studio，图形化管理好用；集成服务可以方便地做数据导入导出；对事务、锁、高可用组Always On的支持也都很成熟。企业内部的ERP、OA、财务系统、政府项目里，SQL Server出现频率很高。
不过SQL Server有两个现实问题让部分团队不得不放弃：一个是授权费用不低，社区版虽免费但限制较多；另一个是它和Linux的配合远不如MySQL和PostgreSQL顺畅。近年来虽然SQL Server能跑在Linux容器里，但整体生态仍以Windows为主，团队如果全是Linux技术栈，维护起来会比较费劲。选它之前先确认两件事：你的部署环境是不是Windows生态？业务是否需要依赖SQL Server特有的功能，比如Reporting Services或Analysis Services？如果答案都否，那开源阵营的库可能会更省心。
2.4 Oracle：重核心业务的老牌选手，仍有很多存量系统要伺候
Oracle是老牌商业数据库，在很多银行、电信、大型央企系统里已经跑了几十年的核心业务，稳定性、并发处理能力、数据保护机制都经过了时间检验。Oracle的逻辑模型和MySQL差别很大，它把数据存放在表空间中，一个数据库实例下面挂多个用户，每个用户访问自己Schema下的表，权限体系也复杂得多。初次从MySQL转过来的人，经常分不清“实例”“表空间”“用户”三者的关系，这是学习Oracle时第一道坎。
更常见的场景是：你的公司要接手一个用Oracle 11g跑了多年的老系统，需要做冷迁移或者备份恢复。Oracle的冷迁移不复杂，但步骤必须严谨：先正常关闭数据库实例，确认没有活动连接，然后把数据文件、控制文件、重做日志文件整目录拷贝到新机器，再在目标环境用相同版本数据库软件启动实例，路径或文件权限不对都会导致启动失败。注意源库和目标库的版本要一致，补丁级别不能差太远。真正容易翻车的反而是字符集不一致、数据文件路径引用错误这类小问题。日常备份用expdp导出dmp文件也算常见操作，但要注意导出的是逻辑数据，大数据量下耗时很长。Oracle目前更适合“系统已经在上面跑着且稳定”的情况，新项目除非有明确的业务或历史原因，否则不建议硬上。
3. 国产数据库这几年越来越多，选型时别忽视它们
3.1 达梦数据库：从Oracle迁移过来的平滑感
达梦数据库是国内关系型数据库里的代表产品之一，也是我在“国产化适配”项目里接触最多的库。之所以很多项目愿意选达梦，一个重要原因是它在语法和操作习惯上高度兼容Oracle。老系统如果原来跑在Oracle上，迁移到达梦的工作量会明显小于迁到MySQL或PostgreSQL，很多PL/SQL写法、系统视图、甚至工具操作习惯都可以平移。这对那些必须完成数据库替换但又不希望业务代码大规模重写的团队来说，价值非常大。
达梦的安装和使用有几个常见操作。DM8安装包解压后可以图形化安装，也可以命令行静默安装，装完以后用DBCA或dminit创建实例。日常连接管理一般用达梦自带的manager图形工具，命令行里用disql。命令行备份的话，达梦有逻辑备份工具dexp和dimp，类似Oracle的exp/imp，可以导出dmp文件再做导入。比如要把整个库导出，可以执行：
dexp SYSDBA/SYSDBA@localhost:5236 DIRECTORY=/data/backup FILE=backup.dmp FULL=Y LOG=backup.log这里的FULL=Y表示全库导出，生产环境建议提前规划好备份目录空间。导入则用dimp，参数基本一一对应。达梦还有一个使用技巧：如果项目后续可能在Oracle和达梦之间来回切换，尽量把Schema名、大小写风格、日期函数统一用一种写法，别混用，否则两边排查问题会非常头疼。
3.2 人大金仓KingbaseES：能快速用Docker跑起来学习和验证
人大金仓的KingbaseES是国内另一款高频出现的数据库，底层和PostgreSQL渊源很深，所以熟悉PostgreSQL的人切过去适应期很短。它支持Oracle、PostgreSQL等多种兼容模式，这在迁移场景里是好消息。对开发者来说，最友好的是KingbaseES也可以像PostgreSQL一样快速用Docker拉起一套环境用于测试和学习。大致命令是：
docker run -d --name kingbase-test \ -e DB_USER=system \ -e DB_PASSWORD=your_password \ -e DB_MODE=Oracle \ -p 54321:54321 \ <人大金仓镜像>官方和社区有些镜像默认没开启SSL，但客户端配置或者管理工具却强制要求SSL连接，就会报“金仓数据库未启用SSL”的错误。此时解决方案通常是：在连接URL或客户端配置里把SSL参数关闭，或者在服务端打开SSL支持并配置证书。我见过不少同事第一次连金仓就卡在这里，还以为是密码或者端口问题。另外金仓的命名习惯和Oracle类似，也强调用户（User）和Schema的关系，创建普通业务用户后要记得授予对应权限，否则应用连上后连建表都会报权限不足。人大金仓常见于有国产化适配要求的电子政务、国企、金融行业项目，评估这类场景时可以优先把它纳入候选。
3.3 瀚高数据库：PG系产品，切换MySQL模式要留个心眼
瀚高数据库同样是PostgreSQL分支的国产关系型数据库。很多人一开始以为它是MySQL分支，其实不是。它的很多运维操作方式、系统表结构都沿袭了PostgreSQL，管理工具也类似。在项目里使用瀚高时，如果业务原本是PostgreSQL，迁移基本顺畅；如果业务原本是MySQL，想切到瀚高的MySQL兼容模式，就要格外小心。切换模式后，字段类型、自增主键实现、日期函数、字符串拼接符号都有差异，MySQL里的AUTO_INCREMENT在瀚高里要用序列或GENERATED BY DEFAULT AS IDENTITY实现，LIMIT ? OFFSET ?虽然支持，但某些自定义函数还是要逐个验证。
这里有个我的建议：不管用达梦、人大金仓还是瀚高，做兼容性评估时先整理一份“迁移点清单”，把自己项目里用到的特殊SQL、数据类型、存储过程全部拉出来，在目标库上逐个执行并记录结果。不要只看简单的建表和增删改查没问题就认为万事大吉，真正踩坑的都是在触发器和复杂查询这类冷门语法上。国产数据库之间也有细微差异，从MySQL迁到达梦和从MySQL迁到瀚高，踩坑点很不一样，提前做一轮冒烟测试比之后上线再补救省太多事。其实现在的金仓、瀚高都已经支持Docker环境部署，搭测试环境的成本很低，做兼容性验证的门槛已经非常小了。
4. 轻量级存储和特殊场景别忽略：SQLite不只是玩具
4.1 SQLite：单文件、零配置，嵌入式项目里的“心头好”
SQLite大概是全世界部署量最大的数据库，手机系统、浏览器、各种桌面软件都在悄悄用它。它最大的特点就是整个数据库只有一个文件，不需要安装服务端，不需要配置端口，程序里引入相应驱动就能直接读写。这种文件型数据库特别适合本地缓存、桌面工具、移动端数据存储、嵌入式设备。你在做课程设计时如果只是想存少量业务数据又不想折腾MySQL服务端，SQLite完全可以一步到位。
我经常给新手推荐的Python小工具开发方式就是标准库内置的sqlite3，写一个数据采集脚本直接落库，完全没有额外依赖。另一个很适合SQLite的场景是临时分析脚本：数据量几百MB以内，用SQL做过滤聚合，比用Excel处理快很多，也比开一个大数据库省事。Linux服务器上临时处理数据时，sqlite3命令行工具几乎都预装了，用起来像高级版awk。
但SQLite有明确边界：它不适合高并发写入的服务端业务，因为同一时刻只有一个写事务能拿到数据库锁，多个线程同时写就可能报database is locked。所以如果你要拿它做正式的Web后端存储，趁早换MySQL或PostgreSQL。它也不太适合数据量超大、需要网络远程访问的场景。再补充一个冷知识：微信本地数据库其实也基于SQLite，但做了加密处理，这也是为什么有人问“微信数据库密钥有什么用”，密钥就是用来解开这些加了密的SQLite文件的，离开了密钥基本无法直接读取数据。
4.2 Linux下的单文件数据库和高速数据导入导出
如果觉得SQLite在类型和功能上太简单，Linux下还可以考虑用文件型数据存储的其他方案，比如用CSV/Parquet配DuckDB做数据分析。不过DuckDB更多定位在分析场景而不是业务事务库，和SQLite不是同一个赛道的替代品。回到主流场景，很多业务中数据要从Excel导入数据库，SQLite的.import命令或者MySQL的LOAD DATA INFILE都能搞定。导入Excel时最常见的坑压根不在数据库，而在文件本身：很多Excel导出的CSV根本不是纯UTF-8编码，直接用工具导入会得到一堆乱码；或者字段里含有逗号、换行没有被正确转义。最稳妥的做法是把Excel另存为真正的UTF-8 CSV，或者先用DBeaver、Navicat这类可视化工具预览一下导入效果。
一个被问过无数次的问题是ArcGIS连接Excel表时报“连接到数据库失败。常规功能故障，外部表不是预期的格式”。这多半不是数据库问题，而是Microsoft Access Database Engine驱动版本不匹配。64位程序需要64位驱动，如果你只装了32位Office，自带的Access驱动是32位，ArcGIS很可能就连接不上。还有一种情况是文件后缀名是.xlsx但内容其实是老版.xls或用WPS另存出来的结构，外部表格式不识别。解决办法很简单：按ArcGIS的位数装对应版本的AccessDatabaseEngine驱动，并且用Excel 2016以上版本把文件另存为标准xlsx。这本质上跟“数据库本身”没关系，但它出现在业务链路里，不搞清楚会浪费大量时间。
4.3 从Access到ODBC驱动的历史遗留坑
数据库相关报错里还有一个特别典型的老问题，就是“请先安装Access数据库64位系统驱动程序”以及“64位引擎不支持DBC数据，只支持Access数据”。你一看就明白，这是典型的驱动位数和应用位数不匹配。Windows系统上的Access数据库引擎有32位和64位两个版本，不能同时安装，你在64位应用里连接Access或者DBF文件时，系统会去找64位ACE驱动；如果机器上只有32位版本，就会提示先安装64位驱动。反过来，如果你用某个32位老软件去读DBF，它可能又要求32位引擎，和已经装好的64位驱动冲突。这类问题通常还伴随“找不到Microsoft.ACE.OLEDB.16.0”等错误。
解决套路也很成熟：先确认你到底在用什么位数的应用，再决定装哪个驱动。如果机器上还需要跑32位和64位两套办公组件，建议用Office 2013官方提供的“AccessDatabaseEngine”不同版本切换，切换时先卸载另一个。很多辅助设计软件、GIS工具、仿真软件（包括一部分人提到过的Multisim访问数据库报错）底层都和Access/ODBC驱动有关，排查思路一模一样。不要一看到“数据库”几字就去数据库服务端查问题，先检查驱动层，往往能少走很多弯路。
5. 非关系型与新生代数据库：缓存、文档、向量和分析场景
5.1 Redis和MongoDB：和关系型数据库关系最紧密的搭档
严格来说Redis是一个内存数据结构存储，而不是传统意义上的数据库。它把数据放在内存里，所以读写速度极快，常见用途是缓存、Session共享、分布式锁、排行榜、消息队列的轻量替代。很多Web系统为了抗住高并发，会把热点数据如用户信息、商品详情、验证码放到Redis里，否则所有请求都压到MySQL上，数据库根本扛不住。但Redis的持久化能力再强，也尽量不要把它当作唯一的数据存储，它的核心优势在速度而非数据安全，RDB和AOF两种机制虽然能减少丢失窗口，但都做不到像关系型数据库那样完善的事务和崩溃恢复。
MongoDB则是文档型数据库的代表，适合存放结构灵活的数据。CMS内容、日志记录、爬虫抓取结果、用户行为事件这类字段经常变化的业务，用MongoDB就比关系型舒服很多。你不需要预先设计完整的表结构，改了代码加个字段也不用写ALTER TABLE。但MongoDB的事务能力直到4.0版本才支持多文档事务，且使用限制较多，对需要强一致性的账务流水、订单库存等核心场景，传统关系型数据库依然是更稳妥的选择。很多项目实际上用的是“关系型数据做主存储、Redis做缓存、MongoDB存半结构化数据”的组合方案，选型没必要互相替代，相互配合才是常态。
5.2 向量数据库：AI时代突然流行的新玩家
向量数据库这几年热得不行，原因是AI应用里的语义搜索、图片相似、推荐系统、RAG这类需求越来越多。传统数据库擅长等值查询和范围查询，但你想找“意思相近的另一句话”，靠SQL里的LIKE是做不好的。向量数据库的思路是把文本、图片等内容通过嵌入模型转成一个高维向量，比如一个文本变成一个1280维的浮点数数组，然后对这个向量做相似度检索，找“离目标向量最近”的N条记录。你可以把它想象成在超大文件堆里找内容最接近的几本书，只是靠数学距离而不是靠关键词。
实际的架构中，向量数据库通常不是单独存在的，它往往和业务系统、关系型数据库、对象存储配合使用。元数据仍存在关系型数据库里，向量的向量库只负责相似度召回。如果只是在做学习或原型验证，也可以先用PostgreSQL的pgvector插件感受一下，不一定非得引入一套独立系统。真正生产环境如果数据量达到千万级且对检索延迟有苛刻要求，再考虑Milvus、Qdrant或云厂商向量数据库。选之前你需要先想清楚：业务确实需要向量相似度检索吗？如果只是普通关键词搜索，上向量库属于过度设计。
5.3 Doris和ClickHouse这类OLAP数据库：报表分析场景的“加速器”
Doris和ClickHouse这类分析型数据库在报表场景中的价值，是MySQL完全替代不了的。它们在设计上就采用了列式存储，数据按列压缩存放，做大规模聚合查询时只读取需要的列，再加上向量化执行、并行查询、预聚合等手段，跑亿级数据量的报表查询可以控制在秒级。而传统MySQL在只有几十GB数据时做稍微复杂点的分组统计，可能就要全表扫描加临时表排序，慢得不忍直视。
最近有不少团队把Doris引入到原本只有MySQL的业务里，是因为Doris很贴心地兼容了MySQL的通信协议。也就是说，很多MySQL客户端和ORM可以直接连到Doris上跑查询，Java后端改个数据源就能把分析类请求切过去，业务表结构不用大改。如果你的企业里有很多报表看板、数据大屏、运营分析需求，可以考虑在业务库之外再搭一套分析库，通过一些同步工具把数据从MySQL、PostgreSQL、SQL Server周期性地同步过去。常见的同步工具有基于日志解析的CDC方案，也有定时抽取的ETL工具；跨不同数据库系统同步时要格外注意类型转换和主键冲突。这个领域并没有“万能银弹”，九个库自由组合的同步方案也不是全自动的，数据一致性校验必须自己加进去，否则同步脚本跑了一个月才发现丢了几万行数据，那才是大事故。
6. 数据库日常使用中最容易踩的坑，按问题排查给你照方抓药
6.1 数据库死锁与并发锁，排查先从索引和事务顺序入手
死锁这个概念说直白点，就是两个或多个事务互相等待对方持有的资源，谁也没法继续往下走。比如事务A更新了订单表的某一行，又想去更新用户表；事务B刚好先更新了用户表的同一行，又回头更新订单表。两边各拿一把钥匙还想开同一扇门，不互相让就会卡死。很多死锁其实不是数据库“坏了”，而是代码里事务获取锁的顺序不一致。
处理死锁的第一步是不要慌，先看数据库的错误日志。MySQL 8.0官方文档里推荐用SHOW ENGINE INNODB STATUS查看最近一次死锁信息，里面会打印出两个事务各自执行的SQL和持有的锁，仔细分析就能找到冲突点；达梦、人大金仓这类国产库也在管理工具或日志里提供了类似的死锁检测信息。第二步是优化代码里的事务范围，尽量缩短事务执行时间，避免在事务里做过多的远程调用和人机交互。第三步是合理设计索引，因为如果更新条件无法通过索引定位行，数据库可能会升级成表锁，死锁概率瞬间翻倍。并发锁的问题大多不是数据库引擎不够强，而是并发控制做得太糙。
6.2 数据库连接池为什么要关注，参数不是越大越好
连接池是应用和数据库之间的一层复用机制，它解决了“每次请求都建数据库连接太慢”的问题，默认情况下HikariCP这类连接池会维持一组可用连接，请求到来时从池里取一条连接，结束之后归还。很多人觉得连接池越大越好，这个想法很危险。数据库服务端每个连接都要占用内存和进程资源，连接数设成500，数据库可能还没被打挂，先被自身的线程调度拖垮了。
我在实际项目中踩过这个坑：某个服务默认连接池最大连接数设为10，接口一有并发波动就报“Connection is not available, request timed out”，后来调大到50，问题反而更严重了，因为数据库端已经忙不过来。正确的做法是根据数据库实例的CPU核数、连接类型和业务并发综合估算，不要在应用层无限加大连接池。一个经验参考是：对于常规OLTP系统，连接池大小可以按CPU核心数 × 2 + 磁盘数做初始值，然后压测调整。同时要注意连接池的空闲超时、连接泄漏检测参数，避免后台任务占用了连接没归还，导致正常业务无连接可用。
6.3 增删改查看似基础，改表结构和加约束才是重灾区
增删改查本身并不难，难的是在一张已经有海量数据的表上做结构修改。MySQL早期版本执行ALTER TABLE时，很多操作会触发表重建，数据量大时会造成长时间锁表，导致线上业务直接卡顿。虽然MySQL 8.0的在线DDL能力已经改善不少，但主键修改、字符集转换这类操作仍然可能造成很大的负载波动。我建议在业务低峰期做结构变更，变更前一定要备份，最好先在测试环境用近似的表结构和数据量压一遍，估算执行时间。
另一个经典头大问题是给包含大量重复数据的表加唯一约束。比如你想给用户邮箱加唯一索引，但历史数据里已经存在两个相同的邮箱，直接执行会看到类似“Duplicate entry 'xxx' for key”的报错。正确步骤如下：先写查询找出重复项，处理或删除它们，再创建唯一约束。不要把报错当作“数据库出问题了”，这其实是在保护你没有产生脏数据，只是你需要先把历史数据洗干净。这两类场景都建议在项目里沉淀成操作清单，每次执行前按清单走，能规避大部分误操作。
6.4 数据迁移、脚本导出与冷迁移，顺序对了才不翻车
数据迁移大概是所有DBA和后端开发最头疼的工作之一，它不只是把数据文件拷贝过去就完事，还需要考虑表结构、索引、约束、触发器、自增序列、外键关系这些“附产品”。日常可以从数据库管理工具中直接导出SQL脚本，例如DBeaver里对库或Schema右键就能生成DDL，IntelliJ IDEA自带数据库工具也能导出建表脚本；但工具导出的脚本通常只包含结构或数据中的一层，生产迁移时要两者分别导出并核对。
做跨库迁移时不要直接硬来，建议把流程切成几步：先在测试环境用抽样数据跑一遍迁移脚本，把兼容性问题找出来；正式迁移前做好目标库的完整备份；迁移完成后进行行数一致性校验和关键业务接口的冒烟测试。如果任务是Oracle到新环境的冷迁移，再次强调顺序：正常关机、拷贝数据文件和控制文件到新机器、确保路径和权限一致、启动数据库、检查告警日志。整个过程可以用两个字总结：稳、慢。任何一步跳着走，后面排查的代价都是成倍的。
6.5 主数据库无法访问或数据连接报错，按链路分层查
在实际业务里，“访问数据库时发生错误，主数据库无法访问”这类提示让人烦心，但排查思路其实很清晰。先从客户端往服务端按链路逐层检查：第一层是网络，用ping和telnet检查IP和端口通不通；第二层是进程，确认数据库服务是否正常运行，监听是否启动；第三层是账号权限，登录用户名、密码、host白名单是否匹配；第四层才是数据库内部状态，比如磁盘满了、连接数超限、归档空间不够导致数据库hang住。
有时数据库服务本身是好的，只是应用配置里的连接串写错了主机名或端口。所以我的习惯是先做一个最小化的连接测试：用命令行工具直连数据库，如果能连上，问题就在应用层或网络层；如果命令行都连不上，再往数据库配置方向找。实践里因磁盘空间不足导致数据库无法写入的情况尤其多，df检查一下就能看出来。记住一个原则：排查问题的时候先看现象属于哪一层，再看日志，最后动手改配置。很多人一遇到“主数据库无法访问”就把服务重启一遍，短时间看着恢复了，但根因还留着，后面还是要炸。
选数据库这件事，做技术的人一定要放下“攀比工具”的心态。我见过团队为了追新框架硬换数据库，结果业务代码改到崩溃；也见过守着旧Oracle系统不敢动，其实早就该引入一套OLAP库专门分担报表压力。数据库选型没有标准答案，最合适答案往往要结合数据规模、事务要求、团队技能、部署环境甚至预算一起来判断。我自己更愿意花时间先写清楚业务需要，再对比数据库特性，最后做一轮小规模压测验证。如果你刚开始学习，我建议你先老老实实把一个数据库用得滚瓜烂熟，把索引、事务、锁、备份这些基本功练扎实，再根据项目需要横向扩展知识面。最后分享一个小技巧：接一个新项目时，不管项目文档咋写的，先自己用命令行连一下数据库，看看版本、字符集、慢查询日志开没开，这几分钟能帮你提前发现一大半隐患。
