【注意】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 直接使用字符串进行比较，避免了隐式类型转换，提高查询性能和结果的准确性。这也要求我们，在日常开发中，要关注细节，程序中严格按照字段数据类型来赋值，进而规避这样的疏漏。