企业官网建设流程全解析

1. 一个看似简单却天天踩坑的话题：达梦数据库的大小写敏感

先说个真实场景。某天晚上应用版本上线，业务方报过来一个异常：某个新功能模块在测试环境跑得好好的，一上生产就报“表或视图不存在”。开发同学查了半天，SQL语句翻来覆去对了好几遍，表名明明是order_info，库里面也确实有这张表，可就是报错。最后DBA一查，生产库初始化的时候把大小写敏感设成了敏感模式，测试库用的是不敏感模式，开发同学写SQL时习惯性全小写，测试环境没问题，生产环境直接翻车。

这种问题在达梦数据库上特别常见。达梦数据库是国内使用范围很广的国产关系型数据库，它在初始化实例和建库的时候会有一个关键参数决定整个数据库的大小写策略，这个参数一旦定下来，后期想再改非常麻烦，基本等于要重新建库。很多人一开始没重视，等到应用上线了才开始头大。

这篇文章就把达梦数据库大小写敏感这件事从头到尾掰扯清楚：它到底是什么、底层怎么运作的、会影响到哪些地方、怎么排查、以及从别的数据库迁过来怎么适配。适合正在用达梦或者准备从Oracle、MySQL迁移到达梦的开发和DBA朋友，看完能少走不少弯路。

2. 先把基础概念弄清楚：大小写敏感的底层逻辑

2.1 数据库大小写敏感到底指什么

在关系型数据库里，“大小写敏感”其实涉及两件事：一是标识符，也就是表名、列名、用户名、视图名这些对象的名字；二是数据本身，也就是存储在字段里的字符串值在比较、排序、去重时是否区分大小写。

以达梦为例，在大小写敏感的模式下：

• 不带引号写出来的标识符，统一被转成大写存储。你写select * from student，达梦内部会把它解析成SELECT * FROM STUDENT，所以如果你的表是用"student"这种带引号方式创建的小写表名，直接写不带引号的student是查不到的，必须写"student"才行。
• 字符串数据比较时严格区分大小写。'abc' = 'ABC'的结果是 FALSE，WHERE name LIKE '%zhang%'也匹配不到Zhang。
• ORDER BY排序时也区分大小写，大写字母排在小写字母前面，具体看字符集的排序规则。

而在大小写不敏感的模式下，标识符不管怎么写都会统一转成大写存储，字符串比较时不区分大小写，'abc' = 'ABC'是 TRUE，LIKE 查询也能匹配到不同大小写的数据。

再说直白一点：敏感模式就像你注册账号时系统明确告诉你“用户名区分大小写”，Admin和admin是两个人；不敏感模式就是“邮箱地址不区分大小写”，写哪个都能找到同一个人。

2.2 达梦为什么默认敏感：与Oracle的兼容性设计

很多人刚接触达梦时会问，为什么不像MySQL那样搞个默认不敏感？这里有个重要的历史背景。达梦数据库从一开始的设计目标就包含“高度兼容Oracle”，目标用户很大一部分是从Oracle迁移过来的存量应用。Oracle的行事风格就是默认大小写敏感，不带引号的标识符一律转成大写存储，字符串比较天然区分大小写。达梦为了尽可能降低Oracle应用迁移的成本，默认也采用同样的策略，这样很多原来跑在Oracle上的SQL，迁到达梦后行为基本一致，不需要大量改写。

这个设计思路本身没有错，问题在于它给习惯了MySQL开发风格的人带来了认知冲击。一个团队里如果同时有Oracle背景的DBA和MySQL背景的开发，大家默认的“正确写法”完全不一样，就容易出case开头那种事故。

2.3 敏感模式下标识符的存储规则

要彻底理解这个问题，就要看达梦在解析SQL时对标识符做了什么处理。

达梦的SQL解析器在处理标识符时遵循这样的规则：

• 不带双引号的标识符，会被统一转换为大写后再去匹配元数据。比如你写create table student(...)，达梦实际创建的表名是STUDENT。
• 带双引号的标识符，会严格保留双引号内的原始大小写。比如create table "student"(...)，创建的表名就是小写的student。
• 写SQL引用对象时也同样适用：不带引号写STUDENT或student，最终解析都是STUDENT；要精确匹配小写的student，必须写成"student"。

这个规则和Oracle几乎一模一样。理解了这一点，很多莫名其妙的报错就能想通了。比如你之前用"Student"建了张表，后面写select * from Student，不带引号，解析出来是STUDENT，元数据里根本没有STUDENT，于是报“无效的表名”。

注意：这里说的“敏感”指的是建库时的参数CASE_SENSITIVE，它不是会话级参数，不能在某个连接里动态改，是在初始化数据库时定死的。后面会专门讲。

3. 建库时的一次性选择：CASE_SENSITIVE参数

3.1 参数含义与设置方式

达梦数据库初始化实例时，有个特别关键的参数叫CASE_SENSITIVE，中文叫“标识符大小写敏感”，可设的值就是两个：1 和 0。

• CASE_SENSITIVE=1：大小写敏感模式，这是达梦的默认值。
• CASE_SENSITIVE=0：大小写不敏感模式。

设置方式有两种常见场景。

第一种是用命令行工具dminit初始化实例，直接加参数：

./dminit PATH=/dm/data CASE_SENSITIVE=1 DB_NAME=DMDB INSTANCE_NAME=DMSERVER

如果想建不敏感的库，把CASE_SENSITIVE=1改成CASE_SENSITIVE=0就行。

第二种是在使用数据库管理工具创建数据库实例时，图形化界面上会有一个“大小写敏感”的选项，默认勾选，取消勾选就相当于CASE_SENSITIVE=0。

关键提醒：这个参数只影响当前初始化出来的这个数据库实例，一个达梦安装目录下可以存在多个实例，每个实例可以有不同的设置。所以从技术上说，你可以在同一套软件上同时维护一个敏感库和一个不敏感库。

3.2 敏感与非敏感模式的行为差异对比

我整理一个对照表，方便快速看两个模式下各种操作的区别。

这个表可以说就是全文的核心了，实际开发中遇到的问题，十有八九能在这个表里找到原因。

3.3 选错模式的补救办法

先说结论：如果你的库已经用某个模式跑了很久，里面建了大量表、存了大量数据，那基本上不存在“改个配置就切换”的可能。想从敏感模式改成不敏感模式，官方支持的路径就是把数据逻辑导出，重新初始化一个新库，再导入回来。因为大小写策略不仅影响元数据存储，还会影响实际数据的内容、索引结构、统计信息，不可能原地修改。

所以建库之前，一定要想清楚自己的应用场景。我的建议是：

• 新项目、团队技术栈偏MySQL风格、SQL写法五花八门、没有严格的命名规范约束，选CASE_SENSITIVE=0更省心。
• 项目是从Oracle迁移过来的存量应用、团队有成熟的“全大写”规范、对性能和精细化控制要求高，选CASE_SENSITIVE=1更合适。

曾经有个客户，因为是国产化替代项目，Oracle换达梦，数据库初始化时随手用了默认值，迁移做完测试也过了。结果到了业务系统联调阶段，Oracle那边原来一堆小写表名，因为导出工具把表名都转成了小写，到达梦敏感模式下全部失效，数据导不进去，应用起不来。最后只能加班重新初始化一个不敏感库，导入导出折腾了两天才解决。这就是选错模式的代价。

4. 从字符串比较到对象名解析：敏感模式影响面全梳理

4.1 字符串比较与LIKE查询

在敏感模式下，普通等值比较是严格区分大小写的。

SELECT * FROM T_USER WHERE NAME = 'Admin';

这条语句在敏感模式下只能查到NAME字段精确等于Admin的行，ADMIN、admin都不行。这在用户登录场景里就非常微妙。比如你的登录语句写的是：

SELECT * FROM T_USER WHERE LOGIN_NAME = 'Admin' AND PASSWORD = MD5('123456');

应用层传进来的用户名如果大小写和注册时不一致，在敏感模式下直接查不到用户，表现为“用户不存在”或者“密码错误”。而同一个应用跑在MySQL上，默认不敏感，哪怕用户名大小写写错了也能登录。很多从MySQL迁过来的应用，最容易在这类地方出隐性bug。

LIKE查询也是同样逻辑：

SELECT * FROM T_PRODUCT WHERE NAME LIKE '%phone%';

敏感模式下匹配不到Phone、IPHONE这些值。如果业务上要求模糊搜索不区分大小写，就得这样写：

SELECT * FROM T_PRODUCT WHERE UPPER(NAME) LIKE '%PHONE%';

但是要注意，对字段套UPPER()之后，这一列上的普通索引基本就失效了，全表扫描性能堪忧。如果需要频繁做这种不区分大小写的模糊搜索，有两个思路：一是建函数索引，达梦支持在表达式上建索引；二是额外维护一个全大写的冗余列，配合常规索引使用。两个方案在达梦里都可行，看业务规模来选。

4.2 对象名的存储与解析规则

这部分是大小写敏感影响最深的地方，因为对象名错了，SQL直接跑不起来。

前面说了，不带引号的标识符统一转大写。这里展开一下对日常开发的三点影响：

第一，建表语句里的表名和字段名怎么写，不等于实际存的就是什么。你写create table userInfo(id int, userName varchar(50))，实际上建的表是USERINFO，列是ID和USERNAME。后面写select username from userinfo也能正常跑，因为解析的时候都转成了大写。

第二，如果你用工具比如达梦管理工具、数据迁移工具去导数据，工具里如果给对象名自动加了双引号并且保留了原始大小写，导进敏感库之后就很容易出现"userInfo"这种小写混合表名。之后所有引用这张表的SQL都必须带双引号、保持相同大小写，否则报对象不存在。这种表名是开发人员的噩梦，排查起来非常痛苦。

第三，应用层如果用ORM框架自动建表、自动生成SQL，不同框架对大小写的处理策略不一样。有的框架会自动加双引号保留大小写，有的是全大写，有的是全小写，到了达梦敏感模式下就会产生各种组合。遇到ORM建的表查不到、表名被莫名加上引号之类的问题，基本都可以从这条规则里找到答案。

常见的报错是“无效的表名”或“表或视图不存在”。看到这两个错误，第一反应就应该是去确认一下元数据里的实际大小写，用引号试一下：

SELECT * FROM "userInfo";

如果能查到，那就说明问题是大小写不匹配引起的。

4.3 排序规则与索引影响

排序方面，敏感模式下ORDER BY默认按字符集的二进制值排序，大写的字母编码值小于小写字母，所以一样是abc开头的数据，ABC排在abc前面。这个顺序在中文场景下感知不强，但英文数据多的话就很明显。

索引方面也要注意。达梦的普通索引在敏感模式下也是区分大小写的。如果你在LOGIN_NAME列上建了唯一索引，那么Admin和admin会被当成两个不同的值，都能插入成功。如果业务逻辑认为登录名不区分大小写，这就成了数据一致性的隐患——同一用户可能被录入两条记录。

解决方案也一样：要么在应用层统一存储的全大写或者全小写，要么对列建函数索引做唯一约束，比如：

CREATE UNIQUE INDEX IDX_USER_LOGIN_UPPER ON T_USER(UPPER(LOGIN_NAME));

这样就能保证无论应用层传入什么大小写组合，数据库里同一个登录名只能存在一份。

5. 实战排查：如何快速判断当前库的大小写设置

5.1 通过系统视图查询方法

接手一个别人建的库，第一件事就是先确认它是什么模式。用管理工具连接后，执行一条查询就能看到当前实例的关键配置：

SELECT CASE_SENSITIVE FROM V$DM_INI;

返回1表示大小写敏感，返回0表示不敏感。这个视图同时还能看到其它实例参数，比如兼容模式、页大小、字符集等，建议DBA接手新库时顺手查一遍。

如果觉得V$DM_INI长得太宽不好定位，也可以这样过滤：

SELECT * FROM V$DM_INI WHERE PARA_NAME = 'CASE_SENSITIVE';

结果集里能看到参数名、当前值、默认值、参数类型等信息。注意别把CASE_SENSITIVE写成其它名字，这个是准确的参数名。

5.2 不用系统视图的快速验证法

有些环境权限受限，或者只是想快速确认，可以用另外两种方式验证。

第一种是查元数据视图。达梦的系统表里存了所有对象，尝试创建一张带引号的小写测试表：

CREATE TABLE "test_case_tmp"(id int); SELECT * FROM test_case_tmp; SELECT * FROM "test_case_tmp";

如果第二条不带引号的查询报错、第三条带引号的查询正常，说明是敏感模式；如果两条都能查到，说明是不敏感模式。测完记得把测试表删掉：

DROP TABLE IF EXISTS "test_case_tmp";

第二种是直接做字符串比较：

SELECT CASE WHEN 'ABC' = 'abc' THEN 'INSENSITIVE' ELSE 'SENSITIVE' END AS MODE_TYPE;

结果集返回INSENSITIVE就是不敏感模式，返回SENSITIVE就是敏感模式。这个方法最快，一行SQL就够。

个人建议平时多用系统视图查法，一是准确，二是顺便能看到其它相关参数，对库的整体情况心里有底。

6. 从其它数据库迁移到达梦的适配经验

6.1 从Oracle迁移的情况

如果你的源库是Oracle，迁移到达梦时情况相对乐观，因为两者大小写策略高度一致。

Oracle下不带引号的表名、列名，存储在数据字典里就是大写。用常规迁移工具导出时，对象名本身就以大写形式存在，导到达梦敏感模式下毫无障碍。原来在Oracle上跑得好好的SQL语句，到达梦敏感模式下也能正常执行。

真正需要注意的是两种情况。一种是原来Oracle里就存在带引号的小写表名，这种属于Oracle里的“异类”用法，迁移时一定要和业务方确认，尽量在迁移过程中统一改成大写，否则到达梦里会变成“异类中的异类”。另一种是存储过程、触发器里的动态SQL，里面如果用了双引号拼接对象名，迁移后要逐一检查。

6.2 从MySQL迁移的情况

从MySQL迁移到达梦，或者新开发的应用原是MySQL风格，这是问题高发区。MySQL在Linux下虽然表名区分大小写，但列名不区分、字符串比较不区分，整体习惯是“大小写混用无所谓”。到了达梦敏感模式下，这种习惯会让SQL频繁报错。

迁移前需要做的事就三件：

第一，统一SQL书写规范。所有对象名统一用大写，或者统一用小写然后不带引号。显式大写最稳妥，大写、加不加引号都能对应上；统一小写不带引号也能被转成大写，效果一样。最怕的就是一会儿大写一会儿小写，还时不时加引号。

第二，检查代码里的字符串比较逻辑。之前在MySQL下不区分大小写的比较，到达梦敏感模式下结果会变。比如根据用户输入的用户名去查用户表，登录逻辑在MySQL下正常，到达梦下可能就登录不了。解决办法是在查询条件上用UPPER()函数统一转换，或者迁移时直接把数据统一成一种大小写形式。

第三，对历史数据做清洗。原来MySQL里可能存在Admin、admin同时存在的脏数据，在MySQL不敏感模式下业务碰巧没出问题，到达梦敏感模式下就会产生歧义。比如主键、唯一索引、关联查询都可能被影响。清洗方案是按大小写归类、合并、去重，这个动作建议在数据迁移过程中做，不要等上生产了再补救。

6.3 开发规范层面的建议

根据我实际参与项目的情况，强烈建议团队在开发规范里明确规定以下几条：

• 所有建表语句、SQL语句中的表名和列名，统一不写双引号。
• 如果团队习惯了用小写写SQL，可以继续全小写，但不要部分小写、部分大写混合写。
• 应用层配置的数据源连接字符串、ORM映射注解，不要手动给表名加引号，除非确认该表就是带引号创建的特殊表。
• 写SQL时对于字段值的比较，业务上要求不区分大小写的场景，显式使用UPPER()或LOWER()包裹两侧表达式，不要依赖数据库默认行为。
• 建库前由DBA和架构师共同确认CASE_SENSITIVE的取值，并且把决定记录下来，避免后续团队成员互相猜。

这几点看着普通，但很多从上到下都很规范的团队，恰恰是栽在这些约定上。因为数据库默认行为和开发习惯不一致时，小问题被放大成大事故只是一瞬间的事。

7. 高频问题排查速查表

把我在实际支持和答疑过程中遇到的高频问题整理成一个速查表，方便大家定位问题。

这张表覆盖了大多数咨询过我的人的问题。如果你遇到的情况不在里面，多半也和大小写有关，可以用第5章的验证方法快速定位。

8. 收尾：一些碎碎念的经验

写这些内容的时候，我脑子里反复出现过同一个画面：凌晨两点，客户现场的会议室里，几个开发人员围着一块屏幕，盯着一条报错的SQL，怎么都不明白为什么测试库能跑、生产库不能跑。最后发现只是两个库初始化时一个勾选了大小写敏感、一个没勾选。

这种问题一点都不高级，但它造成的后果比很多高级问题都要严重。达梦数据库的CASE_SENSITIVE参数，做DBA的人可能觉得就是个初始化选项，但到了应用开发、数据迁移、故障排查的层面，它就是决定项目顺畅程度的一把隐形钥匙。

最后再分享一个落地小技巧：如果团队里同时有多个达梦环境，建议在测试库和生产库初始化时保持完全一致的参数配置，不只是CASE_SENSITIVE，包括页大小、字符集、兼容模式这些初始化参数，全部一致。很多“测试好、生产崩”的现象，就是环境参数差异导致的，大小写敏感只是其中最典型的一种。把这些参数做成一份初始化模板，每次建库都按模板执行，能少踩一大半环境类坑。

希望这篇文章能让准备上手达梦的朋友少走弯路。毕竟折腾数据库已经够辛苦了，能把大小写这种基础问题一次搞清楚，省下的时间干点别的更有价值的事。