去除mysql 大小写敏感

本文详细介绍了MySQL在Linux环境下数据库名、表名、列名及别名的大小写规则,并解释了如何通过调整参数lower_case_table_names来控制这些规则。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

 

 

MySQL在Linux下数据库名、表名、列名、别名大小写规则是这样的:
  1、数据库名与表名是严格区分大小写的;
  2、表的别名是严格区分大小写的;
  3、列名与列的别名在所有的情况下均是忽略大小写的;
      4、字段内容默认情况下是大小写不敏感的。
 
mysql中控制数据库名和表名的大小写敏感由参数lower_case_table_names控制,为0时表示区分大小写,为1时,表示将名字转化为小写后存储,不区分大小写。
mysql> show variables like '%case%';



 

 

 在CentOS安装的MySQL的配置文件中(/etc/my.cnf),是没有lower_case_table_names=1这行的

在CentOS中的my.cnf(/etc/my.cnf)的[mysqld]区段下增加: lower_case_table_names=1

 



 

 

 

 

 

 

 

 

 

 

 

 

捐助开发者

在兴趣的驱动下,写一个免费的东西,有欣喜,也还有汗水,希望你喜欢我的作品,同时也能支持一下。 当然,有钱捧个钱场(右上角的爱心标志,支持支付宝和PayPal捐助),没钱捧个人场,谢谢各位。



 
 
 谢谢您的赞助,我会做的更好!

 

 

<think>我们正在讨论SQL解析中表名大小写的问题。根据用户的问题,他想知道在解析SQL语句提取表名时,是否保留原始表名的大小写格式。同时,用户提供了几个参考引用,其中引用[1]提到:“传入SQL必须大,作者说是希望规范化,但是实际上大小写混用真的很难识别”,这暗示了大小写处理在SQL解析中可能是一个问题。 在SQL标准中,表名的大小写处理取决于具体的数据库管理系统(DBMS)。例如: - 在MySQL中,表名的大小写敏感性取决于文件系统(Linux通常区分,Windows不区分)和配置(lower_case_table_names)。 - 在Oracle中,表名默认是大,但如果用双引号引起来则可以保留大小写。 - 在PostgreSQL中,表名默认是不区分大小写的,但在创建表时如果使用双引号引起来的表名则会区分大小写。 因此,在解析SQL提取表名时,是否保留原始大小写格式需要根据我们的应用场景来决定。一般来说,有两种处理方式: 1. 保留原始大小写:这样能够准确反映SQL语句中表名的书形式,但后续可能需要根据数据库的实际存储进行转换(例如,Oracle中需要将表名转换为大来查询系统表)。 2. 统一转换为大或小:这样便于统一处理,避免因为大小写问题导致表名无法匹配,但可能会丢失原始的大小写信息。 根据引用[1]中的描述,有些解析器要求SQL语句全部大,这是因为它们内部将表名统一转换为大(或小)来处理,以避免大小写混用带来的识别困难。 因此,回答用户的问题:在解析SQL提取表名时,可以选择保留原始大小写,但通常为了后续处理方便(比如与数据库元数据匹配),我们会统一转换为大或小。具体选择取决于后续使用场景。 另外,在解析过程中,我们还需要注意: - 如果表名被双引号引起来,则应该保留其大小写(如Oracle和PostgreSQL)。 - 如果没有引号,则表名在SQL标准中是不区分大小写的,我们可以安全地转换为统一的大小写。 所以,我们可以这样设计: 1. 提取表名时,如果表名被双引号包围,则保留引号内的内容(包括大小写)。 2. 否则,将表名转换为大(或小)来存储,以便后续统一处理。 这样既照顾了需要区分大小写的场景(使用双引号),又避免了大小写混用带来的问题。 下面,我们根据用户提供的引用[3]中提到的Hive血缘解析,以及引用[4]中的样例SQL,可以看到Hive SQL中表名通常是不区分大小写的,但Hive在存储元数据时会将表名转换为小。因此,在解析Hive SQL时,通常将表名转换为小。 总结:是否保留原始大小写格式取决于数据库系统的要求。在解析时,我们通常将表名转换为统一的大小写(如小)以便处理,除非遇到双引号引起来的表名则保留其大小写。 根据上述分析,我们可以修改之前的解析函数,在提取表名后,根据是否被双引号引起来决定是否转换大小写。但注意,在解析过程中,我们可能需要先去除引号,然后判断是否保留大小写。 修改解析函数中的表名提取部分: - 如果表名标识符被双引号包围,则去除引号并保留内部的大小写。 - 否则,去除引号(如果有的话,比如MySQL中使用反引号)并转换为统一大小写(例如小)。 示例代码修改如下(在提取表名后): ```python def extract_table_name(token): # 假设token是表名标识符字符串 if token.startswith('"') and token.endswith('"'): table_name = token[1:-1] # 去除双引号 return table_name # 保留大小写 elif token.startswith('`') and token.endswith('`'): # MySQL风格的引号,去除引号并转换为小(根据MySQL的配置,但通常不区分大小写,我们统一小) table_name = token[1:-1].lower() return table_name elif token.startswith('[') and token.endswith(']'): # SQL Server风格的引号 table_name = token[1:-1].lower() return table_name else: # 没有引号,统一转换为小 return token.lower() ``` 但是,需要注意的是,在解析SQL时,我们可能已经将整个SQL语句转换为大或小(如引用[1]中要求SQL大),这可能会影响我们识别引号。因此,更好的做法是在解析之前保留原始字符串,然后在提取表名时处理引号。 另外,在递归解析子查询时,也要注意保持同样的处理逻辑。 因此,回答用户的问题:在解析SQL提取表名时,我们通常不保留原始大小写,而是统一转换为小(或大),除非表名被双引号引起来(表示区分大小写)则保留原始大小写。 这样,我们既能够处理大多数不区分大小写的场景,也能够兼容需要区分大小写的场景。 最后,生成相关问题: 1. 不同数据库系统对表名大小写的处理方式有哪些差异? 2. 在SQL解析中如何处理被引号引起来的表名? 3. 如何设计一个能够适应多种SQL方言的表名提取器? 4. 在Hive SQL解析中,表名的大小写处理有什么特殊之处? 5. 表名大小写转换是否会影响SQL语句的执行结果?</think>在SQL解析中提取表名时,**是否保留原始大小写格式取决于具体的数据库系统和解析需求**。以下是关键分析: ### 1. **数据库系统的区分大小写规则** - **区分大小写的系统**(如Linux下的MySQL、PostgreSQL): - 表名`"MyTable"`和`"mytable"`被视为不同对象 - **必须保留原始大小写**才能正确识别表 - 解析示例:`SELECT * FROM "MyTable"` → 提取`MyTable` - **不区分大小写的系统**(如Windows下的SQL Server、Oracle): - 表名`MyTable`和`mytable`被视为相同对象 - **可统一转换为小/大**简化处理 - 解析示例:`SELECT * FROM MyTable` → 提取`mytable`(标准化后) ### 2. **SQL语句的引号使用** - **带引号的表名**(如`"MyTable"`, `` `MyTable` ``): - 明确要求区分大小写 - **必须保留原始大小写**[^1] - 解析逻辑: ```python if token.startswith(('"', '`', '[')): # 识别引号 table_name = token.strip('"`[]') # 保留内部大小写 ``` - **无引号的表名**: - 可安全转换为统一大小写 - 解析逻辑: ```python else: table_name = token.lower() # 或 upper() ``` ### 3. **最佳实践建议** 1. **默认标准化处理**: ```python def extract_table_name(token): if re.match(r'["`\[]', token): # 检测引号 return re.sub(r'^["`\[]|["`\]]$', '', token) # 去引号保大小写 return token.lower() # 无引号转小 ``` - 输入`"Orders"` → 输出`Orders` - 输入`orders` → 输出`orders` 2. **元数据关联场景**: - 需与数据库系统表(如`information_schema.tables`)对比时 - **保留原始大小写**确保精确匹配[^3] 3. **血缘分析场景**: - 如Hive血缘解析需保持大小写一致性 - 子查询中的临时表名(如`(SELECT...) base`)可忽略大小写[^4] ### 4. 测试案例 ```sql /* 测试SQL */ SELECT * FROM "CustomerData" c JOIN (SELECT * FROM order_details) od ON c.id = od.cust_id ``` 解析结果: - `CustomerData`(保留大C) - `order_details`(转为小) ### 5. 各数据库处理对比 | 数据库 | 默认大小写敏感 | 带引号处理 | 建议解析方式 | |--------------|----------------|---------------------|--------------------------| | MySQL | 取决于文件系统 | 严格保留大小写 | 检测`` ` ``引号保留大小写 | | Oracle | 不敏感 | 双引号内保留大小写 | 检测`"`引号保留大小写 | | SQL Server | 不敏感 | 方括号内不改变大小写| 检测`[]`保留原始格式 | | PostgreSQL | 敏感 | 双引号内保留大小写 | 始终保留原始大小写 | ### 总结建议 - **优先保留带引号表名的大小写** - **无引号表名统一转为小/大** - **关键场景**(如血缘分析、权限校验)**保持原始大小写**[^3] - 使用专业解析库(如`sqlparse`/`JSqlParser`)处理边界情况
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值