一个在使用方法上的低级错误（MySQL场景）
原创
一个在使用方法上的低级错误（MySQL场景）
原创
薛晓刚-
发布于 2026-01-07 14:08:18
发布于 2026-01-07 14:08:18
首先申明这个技术含量不高
- 初始化问题数据。注意这里的t代表时间，数据类型是字符串。
- 为什么用字符串来表示时间？那这就是问题所在。当初创建的人不懂。
- 这个回答不知道满意吗？
mysql> create table t1 (id int,t varchar(20));
Query OK, 0 rows affected (0.02 sec)
mysql> insert into t1 values (1,'2026-01-01 01:00:00');
Query OK, 1 row affected (0.00 sec)
mysql> insert into t1 values (2,'2026-01-01 10:00:00');
Query OK, 1 row affected (0.00 sec)
mysql> insert into t1 values (3,'2026-01-02 02:00:00');
Query OK, 1 row affected (0.00 sec)
mysql> insert into t1 values (4,'2026-01-03 02:00:00');
Query OK, 1 row affected (0.00 sec)
mysql> insert into t1 values (5,'2026-01-04 08:00:00');
Query OK, 1 row affected (0.00 sec)
mysql> insert into t1 values (6,'2026-01-02 00:00:00');
Query OK, 1 row affected (0.01 sec)
mysql> select * from t1;
+------+---------------------+
| id | t |
+------+---------------------+
| 1 | 2026-01-01 01:00:00 |
| 2 | 2026-01-01 10:00:00 |
| 3 | 2026-01-02 02:00:00 |
| 4 | 2026-01-03 02:00:00 |
| 5 | 2026-01-04 08:00:00 |
| 6 | 2026-01-02 00:00:00 |
+------+---------------------+
6 rows in set (0.00 sec)- 如果查询小于等于1月2日的。注意我写了等于，但是结果是没有1月2日。这也可以理解。字符串就这样定义，从第一个字符开始算。哪怕是1月2日0点0分0秒也不属于范围。
- 只有条件是小于1月3日，才能看到1月2日。
mysql> select * from t1 where t<='2026-01-02';
+------+---------------------+
| id | t |
+------+---------------------+
| 1 | 2026-01-01 01:00:00 |
| 2 | 2026-01-01 10:00:00 |
+------+---------------------+
2 rows in set (0.00 sec)
mysql> select * from t1 where t<='2026-01-03';
+------+---------------------+
| id | t |
+------+---------------------+
| 1 | 2026-01-01 01:00:00 |
| 2 | 2026-01-01 10:00:00 |
| 3 | 2026-01-02 02:00:00 |
| 6 | 2026-01-02 00:00:00 |
+------+---------------------+
4 rows in set (0.00 sec)- 然后同样的表把字段类型换一下。把时间字段给于正经的时间类型。（不过时间精度只到天，因为有的系统场景只要到天就行了。前面模拟的时分秒的仅仅是为了展示说明0点的边界差异）
- 可以看到，这个小于等于时候是能把1月2日时间查出来的。就这一点的差距，取数能查一天的数据量。
- 我给别人演示，这就是他的问题所在。在Oracle中没这种问题。因为时间类型和字符类型的写法都不一样。
mysql> drop table t2;
Query OK, 0 rows affected (0.01 sec)
mysql> create table t2 as select * from t1;
Query OK, 6 rows affected (0.03 sec)
Records: 6 Duplicates: 0 Warnings: 0
mysql> alter table t2 modify t date;
Query OK, 6 rows affected, 5 warnings (0.05 sec)
Records: 6 Duplicates: 0 Warnings: 5
mysql> select * from t2;
+------+------------+
| id | t |
+------+------------+
| 1 | 2026-01-01 |
| 2 | 2026-01-01 |
| 3 | 2026-01-02 |
| 4 | 2026-01-03 |
| 5 | 2026-01-04 |
| 6 | 2026-01-02 |
+------+------------+
6 rows in set (0.00 sec)
mysql> select * from t2 where t<='2026-01-02';
+------+------------+
| id | t |
+------+------------+
| 1 | 2026-01-01 |
| 2 | 2026-01-01 |
| 3 | 2026-01-02 |
| 6 | 2026-01-02 |
+------+------------+
4 rows in set (0.00 sec)- 再换一下时间类型。这种场景下和第一张字符串时间取值几乎一致，区别是0点0分0秒的能查询的到。如果要1月2日所有的数据，条件还是要写小于1月3日。注意不要带=
mysql> create table t3 as select * from t1;
Query OK, 6 rows affected (0.02 sec)
Records: 6 Duplicates: 0 Warnings: 0
mysql> alter table t3 modify t datetime;
Query OK, 6 rows affected (0.04 sec)
Records: 6 Duplicates: 0 Warnings: 0
mysql> select * from t3;
+------+---------------------+
| id | t |
+------+---------------------+
| 1 | 2026-01-01 01:00:00 |
| 2 | 2026-01-01 10:00:00 |
| 3 | 2026-01-02 02:00:00 |
| 4 | 2026-01-03 02:00:00 |
| 5 | 2026-01-04 08:00:00 |
| 6 | 2026-01-02 00:00:00 |
+------+---------------------+
6 rows in set (0.00 sec)
mysql> select * from t3 where t<='2026-01-02';
+------+---------------------+
| id | t |
+------+---------------------+
| 1 | 2026-01-01 01:00:00 |
| 2 | 2026-01-01 10:00:00 |
| 6 | 2026-01-02 00:00:00 |
+------+---------------------+
3 rows in set (0.00 sec)错误是低级的，再结合数据类型就有点绕。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
评论
登录后参与评论
推荐阅读
目录
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号