数据库查询：参数类型与字段类型不匹配可能导致的问题及解决方案

数据库查询：参数类型与字段类型不匹配可能导致的问题及解决方案

引用

CSDN

1.

https://blog.csdn.net/Rcain_R/article/details/137795103

在数据库查询中，参数类型与字段类型的匹配问题常常被忽视，但这种不匹配可能会导致查询结果不符合预期，甚至引发性能问题。本文通过一个具体案例，深入分析了这种不匹配可能带来的问题，并提供了相应的解决方案。

假设我们现在有这样的一张表：

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类型的这种情况下，存在潜在的问题可能导致查询结果不符合预期，具体可能有：

1. 数据类型不匹配：teach_id字段是varchar类型，意味着它存储的是字符串数据。而您的查询条件直接提供了一个long类型的数值。虽然在某些编程语言或数据库接口中，数值可能会被隐式转换成字符串以便执行查询，但这种转换可能并非总是发生或按照预期方式进行。

2. 隐式类型转换规则： 当比较不同数据类型的值时，MySQL遵循特定的隐式类型转换规则。在本例中，由于teach_id是字符串，而提供的值是数值，MySQL通常会尝试将数值转换成字符串进行比较。转换规则通常是将数值添加引号，形成一个字面字符串。例如，1760192781263546578可能会被转换为'1760192781263546578'。

3. 字符串比较逻辑： 即使数值被正确地转换成了对应的字符串形式，接下来进行的是字符串比较而非数值比较。这意味着，只要teach_id中的字符串以'1760192781263546578'开头，就会被认为匹配。例如，teach_id值为'1760192781263546578abc'或'1760192781263546578000'等都会被查询语句视为匹配项，从而可能导致查询结果包含意外的行。

4. 性能影响： 如果数据库中没有针对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引入人了。