AI 助理
文档备案控制台
开发者社区 数据库 文章 正文

[MySQL优化案例]系列 -- 用TIMESTAMP类型取代INT和DATETIME

2017-11-08 1181
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
RDS AI 助手，专业版
RDS MySQL DuckDB 分析主实例，基础系列 4核8GB
RDS MySQL DuckDB 分析主实例，集群系列 4核8GB
简介：
引言：在以前，我总是习惯用 INT UNSIGNED 来存储一个转换成Unix时间戳的时间值，认为这样做从索引，比较等角度来讲，都会比较高效。现在我们来对比下 TIMESTAMP 和 INT UNSIGNED 以及 DATETIME 这3种类型到底谁更好。

1. 准备

创建一个测试表： 
mysql> CREATE TABLE `t` (
`d1` int(10) unsigned NOT NULL default '0',
`d2` timestamp NOT NULL default CURRENT_TIMESTAMP,
`d3` datetime NOT NULL,
KEY `d2` (`d2`),
KEY `d1` (`d1`),
KEY `d3` (`d3`)
);
然后创建一个存储过程填充数据： 
mysql> DELIMITER //
CREATE PROCEDURE INS_T()
BEGIN
SET @i=1;
WHILE 0<1
DO
SET @i=@i+1;
INSERT INTO i VALUES (1199116800+@i, FROM_UNIXTIME(1199116800+@i), FROM_UNIXTIME(1199116800+@i));
END WHILE;
END;//
DELIMITER ;
时间戳  1199116800 表示  2008-01-01 这个时间点。然后运行存储过程，大概填充几十万条记录后，中止执行，因为上面的存储过程是个死循环，所以需要人工中止。
来看看到底有多少条记录了，以及索引情况： 
mysql> select count(*) from t;
+----------+
| count(*) |
+----------+
|   924707 |
+----------+
mysql> analyze table t;
+--------+---------+----------+-----------------------------+
| Table  | Op      | Msg_type | Msg_text                    |
+--------+---------+----------+-----------------------------+
| test.t | analyze | status   | Table is already up to date |
+--------+---------+----------+-----------------------------+
mysql> show index from t;
+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| t     |          1 | d2       |            1 | d2          | A         |      924707 |     NULL | NULL   |      | BTREE      |         |
| t     |          1 | d1       |            1 | d1          | A         |      924707 |     NULL | NULL   |      | BTREE      |         |
| t     |          1 | d3       |            1 | d3          | A         |      924707 |     NULL | NULL   |      | BTREE      |         |
+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+

2. 对比

2.1 只检索一条记录

mysql> explain select * from t where d1 = 1199579155;
+----+-------------+-------+------+---------------+------+---------+-------+------+-------+
| id | select_type | table | type | possible_keys | key  | key_len | ref   | rows | Extra |
+----+-------------+-------+------+---------------+------+---------+-------+------+-------+
|  1 | SIMPLE      | t     | ref  | d1            | d1   | 4       | const |    1 |       |
+----+-------------+-------+------+---------------+------+---------+-------+------+-------+
mysql> explain select * from t where d2 = '2008-01-06 08:25:55';
+----+-------------+-------+------+---------------+------+---------+-------+------+-------+
| id | select_type | table | type | possible_keys | key  | key_len | ref   | rows | Extra |
+----+-------------+-------+------+---------------+------+---------+-------+------+-------+
|  1 | SIMPLE      | t     | ref  | d2            | d2   | 4       | const |    1 |       |
+----+-------------+-------+------+---------------+------+---------+-------+------+-------+
mysql> explain select * from t where d3 = '2008-01-06 08:25:55';
+----+-------------+-------+------+---------------+------+---------+-------+------+-------+
| id | select_type | table | type | possible_keys | key  | key_len | ref   | rows | Extra |
+----+-------------+-------+------+---------------+------+---------+-------+------+-------+
|  1 | SIMPLE      | t     | ref  | d3            | d3   | 8       | const |    1 |       |
+----+-------------+-------+------+---------------+------+---------+-------+------+-------+

2.2 范围检索

mysql> explain select * from t where d1 >= 1199894400;
+----+-------------+-------+-------+---------------+------+---------+------+--------+-------------+
| id | select_type | table | type  | possible_keys | key  | key_len | ref  | rows   | Extra       |
+----+-------------+-------+-------+---------------+------+---------+------+--------+-------------+
|  1 | SIMPLE      | t     | range | d1            | d1   | 4       | NULL | 121961 | Using where |
+----+-------------+-------+-------+---------------+------+---------+------+--------+-------------+
mysql> explain select * from t where d2 >= from_unixtime(1199894400);
+----+-------------+-------+-------+---------------+------+---------+------+--------+-------------+
| id | select_type | table | type  | possible_keys | key  | key_len | ref  | rows   | Extra       |
+----+-------------+-------+-------+---------------+------+---------+------+--------+-------------+
|  1 | SIMPLE      | t     | range | d2            | d2   | 4       | NULL | 121961 | Using where |
+----+-------------+-------+-------+---------------+------+---------+------+--------+-------------+
mysql> explain select * from t where d3 >= from_unixtime(1199894400);
+----+-------------+-------+-------+---------------+------+---------+------+--------+-------------+
| id | select_type | table | type  | possible_keys | key  | key_len | ref  | rows   | Extra       |
+----+-------------+-------+-------+---------------+------+---------+------+--------+-------------+
|  1 | SIMPLE      | t     | range | d3            | d3   | 8       | NULL | 120625 | Using where |
+----+-------------+-------+-------+---------------+------+---------+------+--------+-------------+
小结：从上面的2次对比中可以看到，对  d1 或  d2 字段检索时的索引长度都是  4，因为  TIMESTAMP 实际上是  4字节的  INT 值。因此，实际应用中，基本上完全可以采用  TIMESTAMP 来代替另外2种类型了，并且  TIMESTAMP 还能支持自动更新成当前最新时间，何乐而不为呢？
作/译者：叶金荣（Email: ），来源：http://imysql.cn，转载请注明作/译者和出处，并且不能用于商业用途，违者必究。
引言：在以前，我总是习惯用 INT UNSIGNED 来存储一个转换成Unix时间戳的时间值，认为这样做从索引，比较等角度来讲，都会比较高效。现在我们来对比下 TIMESTAMP 和 INT UNSIGNED 以及 DATETIME 这3种类型到底谁更好。

1. 准备

创建一个测试表： 
mysql> CREATE TABLE `t` (
`d1` int(10) unsigned NOT NULL default '0',
`d2` timestamp NOT NULL default CURRENT_TIMESTAMP,
`d3` datetime NOT NULL,
KEY `d2` (`d2`),
KEY `d1` (`d1`),
KEY `d3` (`d3`)
);
然后创建一个存储过程填充数据： 
mysql> DELIMITER //
CREATE PROCEDURE INS_T()
BEGIN
SET @i=1;
WHILE 0<1
DO
SET @i=@i+1;
INSERT INTO i VALUES (1199116800+@i, FROM_UNIXTIME(1199116800+@i), FROM_UNIXTIME(1199116800+@i));
END WHILE;
END;//
DELIMITER ;
时间戳  1199116800 表示  2008-01-01 这个时间点。然后运行存储过程，大概填充几十万条记录后，中止执行，因为上面的存储过程是个死循环，所以需要人工中止。
来看看到底有多少条记录了，以及索引情况： 
mysql> select count(*) from t;
+----------+
| count(*) |
+----------+
|   924707 |
+----------+
mysql> analyze table t;
+--------+---------+----------+-----------------------------+
| Table  | Op      | Msg_type | Msg_text                    |
+--------+---------+----------+-----------------------------+
| test.t | analyze | status   | Table is already up to date |
+--------+---------+----------+-----------------------------+
mysql> show index from t;
+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| t     |          1 | d2       |            1 | d2          | A         |      924707 |     NULL | NULL   |      | BTREE      |         |
| t     |          1 | d1       |            1 | d1          | A         |      924707 |     NULL | NULL   |      | BTREE      |         |
| t     |          1 | d3       |            1 | d3          | A         |      924707 |     NULL | NULL   |      | BTREE      |         |
+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+

2. 对比

2.1 只检索一条记录

mysql> explain select * from t where d1 = 1199579155;
+----+-------------+-------+------+---------------+------+---------+-------+------+-------+
| id | select_type | table | type | possible_keys | key  | key_len | ref   | rows | Extra |
+----+-------------+-------+------+---------------+------+---------+-------+------+-------+
|  1 | SIMPLE      | t     | ref  | d1            | d1   | 4       | const |    1 |       |
+----+-------------+-------+------+---------------+------+---------+-------+------+-------+
mysql> explain select * from t where d2 = '2008-01-06 08:25:55';
+----+-------------+-------+------+---------------+------+---------+-------+------+-------+
| id | select_type | table | type | possible_keys | key  | key_len | ref   | rows | Extra |
+----+-------------+-------+------+---------------+------+---------+-------+------+-------+
|  1 | SIMPLE      | t     | ref  | d2            | d2   | 4       | const |    1 |       |
+----+-------------+-------+------+---------------+------+---------+-------+------+-------+
mysql> explain select * from t where d3 = '2008-01-06 08:25:55';
+----+-------------+-------+------+---------------+------+---------+-------+------+-------+
| id | select_type | table | type | possible_keys | key  | key_len | ref   | rows | Extra |
+----+-------------+-------+------+---------------+------+---------+-------+------+-------+
|  1 | SIMPLE      | t     | ref  | d3            | d3   | 8       | const |    1 |       |
+----+-------------+-------+------+---------------+------+---------+-------+------+-------+

2.2 范围检索

mysql> explain select * from t where d1 >= 1199894400;
+----+-------------+-------+-------+---------------+------+---------+------+--------+-------------+
| id | select_type | table | type  | possible_keys | key  | key_len | ref  | rows   | Extra       |
+----+-------------+-------+-------+---------------+------+---------+------+--------+-------------+
|  1 | SIMPLE      | t     | range | d1            | d1   | 4       | NULL | 121961 | Using where |
+----+-------------+-------+-------+---------------+------+---------+------+--------+-------------+
mysql> explain select * from t where d2 >= from_unixtime(1199894400);
+----+-------------+-------+-------+---------------+------+---------+------+--------+-------------+
| id | select_type | table | type  | possible_keys | key  | key_len | ref  | rows   | Extra       |
+----+-------------+-------+-------+---------------+------+---------+------+--------+-------------+
|  1 | SIMPLE      | t     | range | d2            | d2   | 4       | NULL | 121961 | Using where |
+----+-------------+-------+-------+---------------+------+---------+------+--------+-------------+
mysql> explain select * from t where d3 >= from_unixtime(1199894400);
+----+-------------+-------+-------+---------------+------+---------+------+--------+-------------+
| id | select_type | table | type  | possible_keys | key  | key_len | ref  | rows   | Extra       |
+----+-------------+-------+-------+---------------+------+---------+------+--------+-------------+
|  1 | SIMPLE      | t     | range | d3            | d3   | 8       | NULL | 120625 | Using where |
+----+-------------+-------+-------+---------------+------+---------+------+--------+-------------+
小结：从上面的2次对比中可以看到，对  d1 或  d2 字段检索时的索引长度都是  4，因为  TIMESTAMP 实际上是  4字节的  INT 值。因此，实际应用中，基本上完全可以采用  TIMESTAMP 来代替另外2种类型了，并且  TIMESTAMP 还能支持自动更新成当前最新时间，何乐而不为呢？


本文转自叶金荣51CTO博客，原文链接：http://blog.51cto.com/imysql/308818，如需转载请自行联系原作者
文章标签：
云数据库 RDS MySQL 版
索引
关系型数据库
存储
MySQL
Unix
关键词：
云数据库 RDS MySQL 版案例
云数据库 RDS MySQL 版优化
类型int
云数据库 RDS MySQL 版类型
云数据库 RDS MySQL 版datetime
相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发，帮助IT从业者们通过“阿里云Web应用上云解决方案”，了解一个企业级Web应用上云的常见架构，了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。 &nbsp; 相关的阿里云产品：云数据库RDS MySQL 版 阿里云关系型数据库RDS（Relational Database Service）是一种稳定可靠、可弹性伸缩的在线数据库服务，提供容灾、备份、恢复、迁移等方面的全套解决方案，彻底解决数据库运维的烦恼。 了解产品详情:&nbsp;https://www.aliyun.com/product/rds/mysql&nbsp;
科技小先锋
目录
相关文章
运营研究坊
|
9月前
|
SQL 缓存 关系型数据库
MySQL 慢查询是怎样优化的
本文深入解析了MySQL查询速度变慢的原因及优化策略，涵盖查询缓存、执行流程、SQL优化、执行计划分析（如EXPLAIN）、查询状态查看等内容，帮助开发者快速定位并解决慢查询问题。
运营研究坊
367 0
1243767626601764
|
6月前
|
SQL 关系型数据库 MySQL
Mysql数据恢复—Mysql数据库delete删除后数据恢复案例
本地服务器，操作系统为windows server。服务器上部署mysql单实例，innodb引擎，独立表空间。未进行数据库备份，未开启binlog。 人为误操作使用Delete命令删除数据时未添加where子句，导致全表数据被删除。删除后未对该表进行任何操作。需要恢复误删除的数据。 在本案例中的mysql数据库未进行备份，也未开启binlog日志，无法直接还原数据库。
1243767626601764
541 2
蓝易云
|
7月前
|
缓存 关系型数据库 MySQL
降低MySQL高CPU使用率的优化策略。
通过上述方法不断地迭代改进，在实际操作中需要根据具体场景做出相对合理判断。每一步改进都需谨慎评估其变动可能导致其他方面问题，在做任何变动前建议先在测试环境验证其效果后再部署到生产环境中去。
蓝易云
286 6
Unfailed_realme
|
8月前
|
存储 SQL 关系型数据库
MySQL 核心知识与索引优化全解析
本文系统梳理了 MySQL 的核心知识与索引优化策略。在基础概念部分，阐述了 char 与 varchar 在存储方式和性能上的差异，以及事务的 ACID 特性、并发事务问题及对应的隔离级别（MySQL 默认 REPEATABLE READ）。 索引基础部分，详解了 InnoDB 默认的 B+tree 索引结构（多路平衡树、叶子节点存数据、双向链表支持区间查询），区分了聚簇索引（数据与索引共存，唯一）和二级索引（数据与索引分离，多个），解释了回表查询的概念及优化方法，并分析了 B+tree 作为索引结构的优势（树高低、效率稳、支持区间查询）。 索引优化部分，列出了索引创建的六大原则
Unfailed_realme
190 2
技术自由圈/原疯狂创客圈
|
10月前
|
存储 SQL 关系型数据库
京东面试：mysql深度分页 严重影响性能？根本原因是什么？如何优化？
京东面试：mysql深度分页 严重影响性能？根本原因是什么？如何优化？
技术自由圈/原疯狂创客圈
622 8
京东面试：mysql深度分页 严重影响性能？根本原因是什么？如何优化？
青云@yd
|
8月前
|
存储 SQL 关系型数据库
MySQL 动态分区管理：自动化与优化实践
本文介绍了如何利用 MySQL 的存储过程与事件调度器实现动态分区管理，自动化应对数据增长，提升查询性能与数据管理效率，并详细解析了分区创建、冲突避免及实际应用中的关键注意事项。
青云@yd
344 0
蓝易云
|
12月前
|
存储 关系型数据库 MySQL
MySQL细节优化：关闭大小写敏感功能的方法。
通过这种方法，你就可以成功关闭 MySQL 的大小写敏感功能，让你的数据库操作更加便捷。
蓝易云
932 19
青云交（Java大数据AI云原生Python）
|
11月前
|
关系型数据库 MySQL 大数据
大数据新视界--大数据大厂之MySQL 数据库课程设计：MySQL 数据库 SQL 语句调优的进阶策略与实际案例（2-2）
本文延续前篇，深入探讨 MySQL 数据库 SQL 语句调优进阶策略。包括优化索引使用，介绍多种索引类型及避免索引失效等；调整数据库参数，如缓冲池、连接数和日志参数；还有分区表、垂直拆分等其他优化方法。通过实际案例分析展示调优效果。回顾与数据库课程设计相关文章，强调全面认识 MySQL 数据库重要性。为读者提供综合调优指导，确保数据库高效运行。
青云交（Java大数据AI云原生Python）
337 5
游客kufrkwrbkmpsa
|
12月前
|
存储 SQL 关系型数据库
【YashanDB知识库】MySQL迁移至崖山char类型数据自动补空格问题
**简介**：在MySQL迁移到崖山环境时，若字段类型为char(2)，而应用存储的数据仅为&#39;0&#39;或&#39;1&#39;，查询时崖山会自动补空格。原因是mysql的sql_mode可能启用了PAD_CHAR_TO_FULL_LENGTH模式，导致保留CHAR类型尾随空格。解决方法是与应用确认数据需求，可将崖山环境中的char类型改为varchar类型以规避补空格问题，适用于所有版本。
游客kufrkwrbkmpsa
297 17
overmind1980
|
12月前
|
Python Windows
[oeasy]python076_int这个词怎么来的_[词根溯源]整数类型_int_integer_touch
本文探讨了“int”一词的起源及其与整数类型的关联。通过词根溯源，揭示“int”来源于“integer”，意为“完整的数”，与零碎的分数相对。同时分析了相关词汇如“tact”（接触）、“touch”（触摸）及衍生词，如“tangential”（切线的）、“intagible”（无形的）和“integral”（完整的、不可或缺的）。文章还结合编程语言特性，解释了Python作为动态类型、强类型语言的特点，并总结了整型变量的概念与意义。最后预告了后续内容，提供了学习资源链接。
overmind1980
422 11

热门文章

最新文章

  • 1
    TypeError: int() argument must be a string, a bytes原因
  • 2
    关于Int自增字段和GUID字段的性能测试。只有测试，没有分析，呵呵
  • 3
    你对MySQL的int(11)真的了解吗？
  • 4
    POJ1068 Parencodings【用一个int变量作为栈】
  • 5
    int/double/string使用
  • 6
    由int指令引发的中断(1301)
  • 7
    数据类型转换：int()、str()、float()
  • 8
    int 和 String 互相转换
  • 9
    Reverse Integer - 反转一个int，溢出时返回0
  • 10
    32 位和 64 位 JVM 中 int 变量的大小解析
  • 1
    【紧急救援】MySQL CPU 100%！一套组合拳教你快速定位并解决！
    632
  • 2
    MySQL中日期和时间函数的使用指南
    337
  • 3
    MySQL 与 Redis 如何保证双写一致性？
    600
  • 4
    【赵渝强老师】MySQL的事务隔离级别
    352
  • 5
    【Docker】（3）学习Docker中 镜像与容器数据卷、映射关系！手把手带你安装 MySql主从同步 和 Redis三主三从集群！并且进行主从切换与扩容操作，还有分析 哈希分区 等知识点！
    677
  • 6
    MySQL源码编译安装
    1368
  • 7
    MySQL二进制包安装
    696
  • 8
    MySQL包安装 -- SUSE系列（离线RPM包安装MySQL）
    607
  • 9
    MySQL包安装 -- SUSE系列（SUSE资源库安装MySQL）
    561
  • 10
    MySQL包安装 -- Debian系列（离线DEB包安装MySQL）
    2047

    • 相关课程

    更多
  • 云数据库MySQL版快速上手教程
  • 阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
  • MySQL实战进阶
  • 阿里云数据库产品家族及特性
  • 数据库及SQL/MySQL基础
  • 云数据库MySQL快速入门

    • 相关电子书

    更多
  • PolarDB MySQL引擎重磅功能及产品能力盛大发布
  • 阿里云MySQL云数据库产品体系介绍
  • One Box： 解读事务与分析一体化数据库 HybridDB for MySQL

    • 推荐镜像

    更多
  • mysql
    • 下一篇
    极速数仓ClickHouse步入云原生新纪元