数据库选型这件事说实话做过几年项目的人都明白没有“最好”的数据库只有“当前场景下最合适”的数据库。我见过不少团队一上来就奔着最流行的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 ServerWindows技术栈里的老搭档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/SYSDBAlocalhost:5236 DIRECTORY/data/backup FILEbackup.dmp FULLY LOGbackup.log这里的FULLY表示全库导出生产环境建议提前规划好备份目录空间。导入则用dimp参数基本一一对应。达梦还有一个使用技巧如果项目后续可能在Oracle和达梦之间来回切换尽量把Schema名、大小写风格、日期函数统一用一种写法别混用否则两边排查问题会非常头疼。3.2 人大金仓KingbaseES能快速用Docker跑起来学习和验证人大金仓的KingbaseES是国内另一款高频出现的数据库底层和PostgreSQL渊源很深所以熟悉PostgreSQL的人切过去适应期很短。它支持Oracle、PostgreSQL等多种兼容模式这在迁移场景里是好消息。对开发者来说最友好的是KingbaseES也可以像PostgreSQL一样快速用Docker拉起一套环境用于测试和学习。大致命令是docker run -d --name kingbase-test \ -e DB_USERsystem \ -e DB_PASSWORDyour_password \ -e DB_MODEOracle \ -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右键就能生成DDLIntelliJ IDEA自带数据库工具也能导出建表脚本但工具导出的脚本通常只包含结构或数据中的一层生产迁移时要两者分别导出并核对。做跨库迁移时不要直接硬来建议把流程切成几步先在测试环境用抽样数据跑一遍迁移脚本把兼容性问题找出来正式迁移前做好目标库的完整备份迁移完成后进行行数一致性校验和关键业务接口的冒烟测试。如果任务是Oracle到新环境的冷迁移再次强调顺序正常关机、拷贝数据文件和控制文件到新机器、确保路径和权限一致、启动数据库、检查告警日志。整个过程可以用两个字总结稳、慢。任何一步跳着走后面排查的代价都是成倍的。6.5 主数据库无法访问或数据连接报错按链路分层查在实际业务里“访问数据库时发生错误主数据库无法访问”这类提示让人烦心但排查思路其实很清晰。先从客户端往服务端按链路逐层检查第一层是网络用ping和telnet检查IP和端口通不通第二层是进程确认数据库服务是否正常运行监听是否启动第三层是账号权限登录用户名、密码、host白名单是否匹配第四层才是数据库内部状态比如磁盘满了、连接数超限、归档空间不够导致数据库hang住。有时数据库服务本身是好的只是应用配置里的连接串写错了主机名或端口。所以我的习惯是先做一个最小化的连接测试用命令行工具直连数据库如果能连上问题就在应用层或网络层如果命令行都连不上再往数据库配置方向找。实践里因磁盘空间不足导致数据库无法写入的情况尤其多df检查一下就能看出来。记住一个原则排查问题的时候先看现象属于哪一层再看日志最后动手改配置。很多人一遇到“主数据库无法访问”就把服务重启一遍短时间看着恢复了但根因还留着后面还是要炸。选数据库这件事做技术的人一定要放下“攀比工具”的心态。我见过团队为了追新框架硬换数据库结果业务代码改到崩溃也见过守着旧Oracle系统不敢动其实早就该引入一套OLAP库专门分担报表压力。数据库选型没有标准答案最合适答案往往要结合数据规模、事务要求、团队技能、部署环境甚至预算一起来判断。我自己更愿意花时间先写清楚业务需要再对比数据库特性最后做一轮小规模压测验证。如果你刚开始学习我建议你先老老实实把一个数据库用得滚瓜烂熟把索引、事务、锁、备份这些基本功练扎实再根据项目需要横向扩展知识面。最后分享一个小技巧接一个新项目时不管项目文档咋写的先自己用命令行连一下数据库看看版本、字符集、慢查询日志开没开这几分钟能帮你提前发现一大半隐患。