问题:假设我们现在有这样的一张表
CREATE TABLE `test_person` (
`id` int(20) NOT NULL COMMENT '主键',
`name` varchar(20) DEFAULT NULL COMMENT '姓名',
`gender` char(2) DEFAULT NULL COMMENT '性别',
`birthday` date DEFAULT NULL COMMENT '生日',
`created_time` timestamp NULL DEFAULT NULL COMMENT '创建时间',
`updated_time` timestamp NULL DEFAULT NULL COMMENT '修改时间',
`teach_id` varchar(100) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
表中数据:
INSERT INTO test_local.test_person
(id, name, gender, birthday, created_time, updated_time, teach_id)
VALUES(0, '暂时', '男', '2022-10-26', '2022-10-26 10:17:00', '2022-10-26 10:17:02', '1760192781263546523');
INSERT INTO test_local.test_person
(id, name, gender, birthday, created_time, updated_time, teach_id)
VALUES(1, '知识', '女', '2022-10-26', '2022-10-26 10:14:47', '2022-10-26 10:14:49', '1760192781263546578');
INSERT INTO test_local.test_person
(id, name, gender, birthday, created_time, updated_time, teach_id)
VALUES(2, '财富', '女', '2022-10-26', '2022-10-26 10:14:47', '2022-10-26 10:14:49', '1760192781263546584');
INSERT INTO test_local.test_person
(id, name, gender, birthday, created_time, updated_time, teach_id)
VALUES(3, '自由', '女', '2022-10-26', '2022-10-26 10:14:47', '2022-10-26 10:14:49', '1760192781263546545');
INSERT INTO test_local.test_person
(id, name, gender, birthday, created_time, updated_time, teach_id)
VALUES(4, '爱情', '女', '2022-10-26', '2022-10-26 10:14:47', '2022-10-26 10:14:49', '1760192781263546536');
我们要查询teach_id = '1760192781263546578' 的数据;
一般查询我们会:
select * from test_person;
如果我们要查询 teach_id= 1760192781263546578的数据,只需要加上where 即可:
select * from test_person where teach_id = '1760192781263546578';
select * from test_person where teach_id = 1760192781263546578;
那么大家猜想一下,上面的这两个查询的结果是不是一样的呢?
结果: 不一样!!! 实际运行结果如下:
select * from test_person where teach_id = '1760192781263546578';
select * from test_person where teach_id = 1760192781263546578;
其中,入参 1760192781263546578
是 String
类型的值时,查询结果为我们期望的查询;入参为long类型的值时,查询结果非我们期望的数值。
在入参为long型但数据库中字段值类型未varchar类型的这种情况下,存在潜在的问题可能导致查询结果不符合预期,具体可能有:
数据类型不匹配:
teach_id
字段是varchar
类型,意味着它存储的是字符串数据。而您的查询条件直接提供了一个long
类型的数值。虽然在某些编程语言或数据库接口中,数值可能会被隐式转换成字符串以便执行查询,但这种转换可能并非总是发生或按照预期方式进行。隐式类型转换规则: 当比较不同数据类型的值时,MySQL遵循特定的隐式类型转换规则。在本例中,由于
teach_id
是字符串,而提供的值是数值,MySQL通常会尝试将数值转换成字符串进行比较。转换规则通常是将数值添加引号,形成一个字面字符串。例如,1760192781263546578
可能会被转换为'1760192781263546578'
。字符串比较逻辑: 即使数值被正确地转换成了对应的字符串形式,接下来进行的是字符串比较而非数值比较。这意味着,只要
teach_id
中的字符串以'1760192781263546578'
开头,就会被认为匹配。例如,teach_id
值为'1760192781263546578abc'
或'1760192781263546578000'
等都会被查询语句视为匹配项,从而可能导致查询结果包含意外的行。性能影响: 如果数据库中没有针对
teach_id
列建立合适的索引(如唯一索引或普通索引),或者由于类型不匹配导致索引无法有效利用,那么这种查询可能无法利用索引来加速检索,从而导致全表扫描,降低查询效率。即使有索引可用,由于数据类型不匹配造成的隐式类型转换也可能阻止MySQL完全利用索引优化查询。
所以使用 long
型数值直接查询 varchar
类型的 teach_id
字段可能会导致以下问题:
- 查询结果包含非预期的数据,即那些
teach_id
以指定数值开头的行。- 查询性能下降,特别是当表较大且未对
teach_id
列创建合适索引时。
要解决这个问题,确保查询的准确性和性能,建议采取以下措施:
类型匹配:在编写查询时,确保查询条件的类型与列的类型一致。对于本例,应该将
long
型数值转换为等效的字符串形式再进行查询:1SELECT * FROM user WHERE teach_id = '1760192781263546578';
数据模型审查:
- 检查
teach_id
字段的设计是否合理。如果它实际上存储的是数值型数据,考虑将其数据类型改为更合适的数值类型(如bigint
),以保持数据一致性并避免不必要的类型转换。- 确保为
teach_id
创建适当的索引,特别是如果它是用于频繁查询和连接操作的关键字段。
通过以上调整,可以确保SQL查询能够准确地找到目标数据,并尽可能提高查询效率。
写在最后:另外希望大家在写代码的时候,能够注意一下数据库中的字段值和代码中的字段值类型要做到匹配,否则,那就是稳稳的BUG引入人了。