mysql怎么现在时间between两个时间段内的值

让我告诉你我遇到的困难。
前年，我在上海做一个项目，数据库表中有几千条记录。
当时有朋友写了一个查询，在开始时间和结束时间之间直接使用where now()。
起初我认为这很好而且很简单。
结果？检查数据极慢，后台滞后。

后来想想，好像有些不对劲。
如果你想一下，now()是一个函数，每个查询都算作时间。
该表应该在开始时间和结束时间字段上有索引，对吧？但这样一来，索引根本就没有被使用。
直接startTime <= now()和endTime >= now()，就会在这两个字段上激活索引，查询速度立刻变快。
记得更改后，同量数据的查询时间从十几秒降到了不到一秒。

当然，并不是所有事情都那么清楚。
比如去年深圳的另一个项目，数据量只有几百条。
我在开始时间和结束时间之间的某个时间使用了 now() ，感觉很好而且搜索速度很快。
但如果你的数据量增长，你仍然需要使用startTime <= now()和endTime >= now()。

还有一点需要注意，now() 考虑时区。
去年上海项目中，部分客户来自美国，数据时区不同。
如果不注意直接用now()来比较，结果就会乱七八糟。
后来我确定添加了时区处理，保证比较时使用相同的时区，不会出现问题。

总之，为了效率，尤其是数据量较大时，建议使用startTime <= now()和endTime >= now()。
使用索引，速度提高，结果准确。
这件事只有落入陷阱之后才会清楚。

技术分享 | MySQL:一文弄懂时区&time_zone

上周一位客户问我在MySQL安装参数中设置什么时区。
首先，如果您运行的是本地业务，建议在 my.cnf 文件中设置 default-time-zone='+08 :00' 以确保时间显示正确。

然后访客说JAVA应用读取的时间与北京时间相差1 4 个小时。
这个问题其实是由于JDBC参数没有指定时区属性，而MySQL也没有指定全局时区，所以默认使用系统时区CST。
解决办法是按照规范设置MySQL时区，并在连接JDBC时设置serverTimezone参数。

他还问了一个问题；也就是说，对于已经运行了一段时间的企业。
改变MySQL的时区会影响存储的时间类型数据吗？我说不疼。
它仅影响读取时间戳数据类型。
对于日期时间类型；其存储和读取不受时区影响。

此外，我还担心迁移数据时出现时区错误。
特别适用于时间戳。
例如，使用mysqldump导出数据时；默认情况下将使用 UTC 时区。
此时，您需要手动设置 session.time_zone 以确保时间正确。

为了避免这种情况，mysqldump提供了--skip-tz-utc参数，使得导出的数据不使用UTC时区。
另外，导出SQL文件时；默认也使用UTC时区，但在文件头中添加了session_time_zone信息，以保证导出和导入时的时区相同。

无论如何，这些方法应该可以消除您的所有疑虑。
我还在想这个问题。
我觉得时区问题很复杂。

MySQL中的日期时间类型与格式化方式总结

你好~你看的是MySQL的日期和时间类型，对吧？确实，这些类型很容易混淆。
我给大家讲讲我遇到的困难和我的实践经验。

上周，一位客户问我，为什么他们使用时间戳时时间是错误的。
后来我发现它使用的是MyISAM引擎。
我想谈谈：
1 DATE 和 DATETIME 是最常见的。
2 02 3 年，我在上海一家购物中心做系统时，订票系统使用DATE来存储生日，因为谁在乎秒数，对吧？但订单记录应该使用DATETIME(6 )，因为客户反映他们想检查是否有人在某一分钟下了订单，小数点后6 秒就足够了。
记住：DATE是4 个字节，范围是1 000-9 9 9 9 ； DATETIME 是 8 个字节，并且会在 2 03 8 年爆炸（处理闰秒时要小心）。

2 不要忽略 TIME 中的负数！ 2 02 2 年我在深圳做一个物流系统的时候，有一个场景，需要记录异常时段。
例如，-2 3 :4 5 :3 0 表示延迟 2 3 小时 4 5 分 3 0 秒。
当时做测试的人直接报错了，我直接骂他，说数据库支持负时间！ TIME 为 3 字节可变长度，空值必须为 00:00:00，不要将其写为空字符串。

3 今年是最骗人的一年！我在写报表脚本的时候，直接使用了SELECT YEAR(CURDATE())，结果显示2 02 3 年变成了2 003 年！后来发现是2 位数字这些数字将自动映射到 1 9 7 0-2 06 9 年。
现在我在 SQL 中的 YEAR 上添加注释： YEAR(CURDATE()) AS current_year -
注意，00-6 9 算作 2 000。
存储空间只有 1 个字节，但如果出错，则无法更正。

4 时间戳会自动更新，但不要随意使用！ 2 02 1 年我在北京做ERP的时候，使用用户表中的时间戳导入数据所花费的时间就变成了当前系统时间。
后来改成DATETIME，数据恢复正常了。
TIMESTAMP在2 03 8 年（从1 9 7 0年开始）有大爆炸的风险，默认会根据时区变化，所以要特别注意这一点。
它存储4 个字节，但其行为复杂，因此建议仅在业务需求明确时使用它。

我最常用的格式化函数是DATE_FORMAT。
例如，我使用 DATE_FORMAT(order_time, '%Y-%m') 按月汇总客户报告。
STR_TO_DATE也很实用。
我在调试2 02 3 年杭州订单导入时，供应商发送的CSV格式为“2 02 3 -01 -01 08 :00:00”。
我只是将其直接移至 STR_TO_DATE(col1 , '%Y-%m-%d %H:%i:%s')。

简而言之：
将年份保存为YEAR，不要弄复杂。

要自动记录创建/修改时间，请检查TIMESTAMP但引擎（InnoDB默认自动更新）。

准确并自动更新到秒，时间戳。

在其他情况下，DATETIME 是最安全的。
根据要求 日期并使用时间。

如果您有任何疑问，请问我。
别光想这些事，很容易秃头~