【注意】sql语句where条件中的数据类型不一致,不仅存在性能问题,还会有数据准确性方面的bug......

隐式类型转换规则

MySQL 在进行比较操作时,如果比较双方的数据类型不一致,通常会尝试将其中一个数据类型转换为另一个数据类型,以便进行比较。

对于 select * from t_order where order_no = 1538808276987285507 ,当 order_no 为 varchar字符串类型的情况下,MySQL 会把 varchar 类型的 order_no 列的值转换为数字类型,然后再和数字 1538808276987285507 进行比较。

转换过程示例

假设 t_order 表有如下数据:

sql 复制代码
CREATE TABLE t_order (
    order_no varchar(20)
);

INSERT INTO t_order (order_no) VALUES
('1538808276987285507'),
('abc123'),
('123abc');

当执行 SELECT * FROM t_order WHERE order_no = 1538808276987285507; 时,MySQL 会将 order_no 列的值转换为数字类型。具体转换如下:

  • 对于值 '1538808276987285507',转换为数字 1538808276987285507,与查询条件匹配。
  • 对于值 'abc123',由于开头不是数字,转换为数字 0,不与查询条件匹配。
  • 对于值 '123abc',转换为数字 123,不与查询条件匹配。

可能存在的问题

  • 性能问题:隐式类型转换可能会导致索引失效,因为索引是基于原始数据类型创建的。当进行隐式类型转换时,MySQL 无法直接使用索引进行查找,而是需要对每一行数据进行转换和比较,从而降低查询性能。
  • 数据准确性问题 :如果 varchar 列的值不能正确转换为数字,可能会导致意外的结果。例如,'abc' 转换为数字会得到 0,这可能会使查询结果包含一些不符合预期的数据。

关于数据准确性问题,我们再来说道一下。

先执行 INSERT INTO t_order (order_no) VALUES('1538808276987285506')

然后,执行 select * from t_order where order_no = 1538808276987285507 , 会惊奇地发现查询出2条结果!为什么呢?

原因分析:order_no存储的"1538808276987285506"和"1538808276987285507"是19位数值类型,由于整数型的大小在计算机中是有上限,当超出后就会被截断或者科学计数,所以会出现意外的内容。也就是说这个查询sql条件在用数值类型时,由于长度太长,所以被截断了或者被科学计数等特殊处理了,导致查询结果出现不准确。

注重细节、编写严谨的代码

为了避免隐式类型转换带来的问题,建议在编写 SQL 语句时,确保比较双方的数据类型一致。对于上述查询,可以将查询条件修改为字符串形式:

sql 复制代码
SELECT * FROM t_order WHERE order_no = '1538808276987285507';

这样可以确保 MySQL 直接使用字符串进行比较,避免了隐式类型转换,提高查询性能和结果的准确性。 这也要求我们,在日常开发中,要关注细节,程序中严格按照字段数据类型来赋值,进而规避这样的疏漏。

相关推荐
daixin8848几秒前
Redis过期数据的删除策略是什么?有哪些?
数据库·redis·缓存
rufeii3 分钟前
[极客大挑战 2019]FinalSQL--布尔盲注
sql
用户207038619496 分钟前
StateFlow与SharedFlow如何取舍?
android
QmDeve8 分钟前
原生Android Java调用系统指纹识别方法
android
淹没9 分钟前
🚀 告别复杂的HTTP模拟!HttpHook让Dart应用测试变得超简单
android·flutter·dart
陪我一起学编程33 分钟前
MySQL创建普通用户并为其分配相关权限的操作步骤
开发语言·数据库·后端·mysql·oracle
HX4361 小时前
MP - List (not just list)
android·ios·全栈
Albert Tan1 小时前
ORACLE DATABASE 23AI+Apex+ORDS -纯享版
数据库·oracle
程序员编程指南1 小时前
Qt OpenGL 集成:开发 3D 图形应用
c语言·数据库·c++·qt·3d