怎么对Navicat的Mysql表中字段设置区分大小写

记得上次帮同事调试代码的时候，他的表突然报错了。
经过长时间的搜索，我发现两个用户名都使用“admin”。
哎，如果我们在建表的时候加上唯一约束，岂不是省事了？看这个建表语句，用户名加了unique，就可以了。
但他告诉我，之前的表已经使用了好几个月了，数据量相当大。
现在添加此约束会锁定数据库吗？我查了手册，上面说当你添加约束时，InnoDB引擎会自动创建索引。
应该不会花很长时间，但所需时间取决于数据量。
等等，还有一件事。
它的性能最大ID是1 000。
我设置了AUTO_INCRMENT=1 01 8 这是为什么呢？哦，我记得已经删除了几百条数据了，所以AUTO_INCRMENT没有相应改变。
但如果我们现在添加约束，是否会再次重新计算？这是一个真正的痛苦。

mysql中and必须大写吗 mysql关键字大小写规则

关键字不区分大小写。
为了提高可读性，建议使用一致的大写字母，例如 SELECT。

统一风格。
对于 Linux 系统，表名称以小写字母书写；对于 Windows 系统，表名称以大写字母书写。

跨平台开发，统一Lower_case_table_names=1
避免使用保留字命名，必要时添加反引号。

使用 SQL 格式化工具来遵守代码审查实践。

MySQL大小写不敏感的设置mysql不分大小写

嘿嘿，我就来说说我当年掉过的坑吧。
当时我刚刚接手一个使用MySQL的项目，服务器是Linux，所有文件都在/etc/my.cnf中。
我比较懒，只是希望表名不区分大小写，不然就得改很多代码才能改名，比较麻烦。

我在配置文件中找到了 [mysqld] 部分，对其进行了修改并添加了 low_case_table_names=1 保存并重新启动服务。
嘿嘿，确实是这样。
我创建了一个新表，名为“Users”，然后忘记了情况，直接使用users来查询，数据就到了我这里。
当时我觉得味道真好，省去了我很多麻烦。

结果是什么？几个月后，这位年轻人在团队中担任了新职务。
他的表名为 users_info。
这里我没有改变旧的代码，仍然使用Users_info来测试它。
这会导致一条错误消息，指出该表不存在。
我们查了好久，最后发现是大小写敏感导致的。
小伙子气得跺脚说我不要用下划线。

后来我意识到这个设置并不意味着新创建的表可以被意外写入。
这也取决于默认服务器设置。
如果你是Linux且该参数为1 ，那么连接客户端时，输入表名和列名。
最好将它们写成小写或用反引号括起来，就像用户所做的那样，这是最安全的方法。
否则，如果有旧代码没有改的话，很容易出现问题。

那么，你敢使用这个选项吗？我不敢轻易改变。
尤其是在大型项目中，一个动作就能牵动全身。
后来我在代码层面弄清楚了。
比如建表时全部使用小写字母，查询时也转为小写。
这是最安全的方法。
想一想：如果有一天你更改了配置，旧的代码变得不兼容，那么你就雇错了人。

顺便说一句，还有其他东西：一组字符和校对规则。
你也对此应引起重视。
例如，utf8 _general_ci 不区分大小写，但 utf8 _bin 区分大小写。
我曾经有一个项目，但是由于使用了utf8 _general_ci，大小写用户名都能够登录，这就产生了安全风险。
后来改成utf8 _bin，解决了问题。

总之，MySQL 的大小写敏感问题并非小事。
想想你的系统中有多少用户？数据量大吗？如果它们很大，那么你应该小心这个参数。
我当时极力避免麻烦，结果却损失惨重。
现在做某事，我们宁愿制造问题，也不愿提供稳定。

MYSQL如何设置大小写敏感

操作顺序不正确。
首先检查配置文件。

检查 my.ini 并查看small_case_table_names。

默认区分大小写。