判断数据库是判断否存在

写代码查数据库，最烦人的数据不是SQL写错，而是库否连库之前你得先知道那个库到底在不在。直接连吧，判断报错信息糊一脸；不连吧，数据逻辑又没法往下走。库否我见过不少新手直接写`SELECT 1 FROM dual`，判断然后靠捕获异常来判断——能用，数据但笨重得很，库否而且每回都让数据库白忙一趟。判断

换个思路。数据大多数数据库系统都给了现成的库否元数据查询接口，比瞎试连接干净得多。判断拿MySQL说，数据查`information_schema.SCHEMATA`表就行，库否一条`SELECT schema_name FROM information_schema.schemata WHERE schema_name = '你的库名'`搞定。PostgreSQL则是查`pg_database`，SQL Server用`sys.databases`，Oracle得看`v$database`或者`dba_tablespaces`。这些表本来就是存元数据的，查它们不碰实际业务数据，安全又轻快。

但光知道查哪张表还不够。判断“存在”这事，得想清楚你要的是哪种存在。是物理上建了库就算，还是说库里有至少一张表才算？有些团队建库脚本跑一半挂了，库目录建出来了，里面空空如也。这时候你查元数据，库名在列表里，但真要连上去做查询，照样报“No tables used”。所以严谨点，得先看库名在不在，再看库里有没有业务表——两步走，缺一步都会埋坑。

还有个坑是权限。你拿一个只读账号去查`information_schema`，很多时候能查到库名，但那个库你根本没权限访问。反过来，有些数据库对元数据查询做了限制，比如你只能看到自己有权限的库。这时候“存在”就变成了“我能访问的存在”，而不是客观存在。真碰上这种情况，别硬猜，直接拿目标库名试着建个连接，能连上就说明账号有权限，连不上再查元数据排查是库没了还是权限不够。两条腿走路，判断才靠谱。

我自己比较烦那种把所有异常都揉成一团的做法。有人写个函数，里面`try { connect } catch { return false }`，管他是库不存在还是网络断了，一律当“不存在”处理。这哪是判断库存在啊，这是判断“能不能连上”。要是网络抖动一下，库明明好端端的，你程序里就报“库不存在”，运维半夜爬起来查半天，最后发现是防火墙策略改了。分清“不存在”和“不可达”，是写这判断的第一课。

说个实际的例子。我们之前有个定时任务，每天凌晨要往分析库导数据。某天突然报错，说库不存在。我上去一查，库在呢，权限也没变。再细看，发现是那天DBA给数据库做了迁移，IP变了，但应用配置里还写着旧地址。连接超时被代码捕获后，错误类型被粗暴地归类成“库不存在”。改代码，把连接异常和查询结果为空分开处理，问题就再没出现过。

所以判断数据库是否存在，本质上是两件事：第一，用元数据查询确认库在系统里注册过；第二，用真实连接验证当前环境能访问它。前者查字典，后者试敲门。两者都过了，才算真存在。别偷懒省掉第二步，也别在第一步就想着用异常来兜底。代码写干净点，逻辑分清楚，后面维护的人（包括三个月后的你自己）会感谢你的。