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

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

2017-11-08 1138
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
简介：
引言：在以前，我总是习惯用 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;
科技小先锋
目录
相关文章
overmind1980
|
9月前
|
Python Windows
[oeasy]python076_int这个词怎么来的_[词根溯源]整数类型_int_integer_touch
本文探讨了“int”一词的起源及其与整数类型的关联。通过词根溯源，揭示“int”来源于“integer”，意为“完整的数”，与零碎的分数相对。同时分析了相关词汇如“tact”（接触）、“touch”（触摸）及衍生词，如“tangential”（切线的）、“intagible”（无形的）和“integral”（完整的、不可或缺的）。文章还结合编程语言特性，解释了Python作为动态类型、强类型语言的特点，并总结了整型变量的概念与意义。最后预告了后续内容，提供了学习资源链接。
overmind1980
337 11
overmind1980
|
9月前
|
存储 C语言 Python
[oeasy]python077_int类型怎么用_整数运算_integer_进制转化_int类
本文主要讲解了Python中`int`类型的应用与特性。首先回顾了`int`词根的溯源，探讨了整型变量的概念及命名规则（如匈牙利命名法）。接着分析了整型变量在内存中的存储位置和地址，并通过`type()`和`id()`函数验证其类型和地址。还介绍了整型变量的运算功能，以及如何通过`int()`函数将字符串转化为整数，支持不同进制间的转换（如二进制转十进制）。此外，文章提及了关键字`del`的使用场景，对比了Python与C语言中`int`的区别，并总结了整型与字符串类型的差异，为后续深入学习奠定基础。
overmind1980
217 1
overmind1980
|
Python
[oeasy]python036_数据类型有什么用_type_类型_int_str_查看帮助
本文回顾了Python中`ord()`和`chr()`函数的使用方法，强调了这两个函数互为逆运算：`ord()`通过字符找到对应的序号，`chr()`则通过序号找到对应的字符。文章详细解释了函数参数类型的重要性，即`ord()`需要字符串类型参数，而`chr()`需要整数类型参数。若参数类型错误，则会引发`TypeError`。此外，还介绍了如何使用`type()`函数查询参数类型，并通过示例展示了如何正确使用`ord()`和`chr()`进行转换。最后，强调了在函数调用时正确传递参数类型的重要性。
overmind1980
141 3
糜终
|
关系型数据库 MySQL Serverless
MySQL DATETIME 查询条件
MySQL DATETIME 查询条件
糜终
808 1
热爱技术的小郑
|
Java
【Java基础面试五】、 int类型的数据范围是多少？
这篇文章回答了Java中`int`类型数据的范围是-2^31到2^31-1，并提供了其他基本数据类型的内存占用和数值范围信息。
热爱技术的小郑
1306 1
【Java基础面试五】、 int类型的数据范围是多少？
linxinliang
|
自然语言处理 Go 数据安全/隐私保护
对 int 类型的数据加密，有哪些好的方案？
对 int 类型的数据加密，有哪些好的方案？
linxinliang
224 13
爱你三千遍斯塔克
|
关系型数据库 MySQL 数据库
Mysqlbug-Could not create or access the registry key needed for the MySQL applicationto， TIMESTAMP w
Mysqlbug-Could not create or access the registry key needed for the MySQL applicationto， TIMESTAMP w
爱你三千遍斯塔克
560 2
嘟嘟嘟嘟嘟嘟
|
机器学习/深度学习 人工智能 分布式计算
人工智能平台PAI产品使用合集之int类型是否可以为raw feature
阿里云人工智能平台PAI是一个功能强大、易于使用的AI开发平台，旨在降低AI开发门槛，加速创新，助力企业和开发者高效构建、部署和管理人工智能应用。其中包含了一系列相互协同的产品与服务，共同构成一个完整的人工智能开发与应用生态系统。以下是对PAI产品使用合集的概述，涵盖数据处理、模型开发、训练加速、模型部署及管理等多个环节。
嘟嘟嘟嘟嘟嘟
299 2
真的很搞笑
|
运维 Cloud Native 关系型数据库
云原生数据仓库AnalyticDB产品使用合集之布尔类型和int类型可以自动转换吗
阿里云AnalyticDB提供了全面的数据导入、查询分析、数据管理、运维监控等功能，并通过扩展功能支持与AI平台集成、跨地域复制与联邦查询等高级应用场景，为企业构建实时、高效、可扩展的数据仓库解决方案。以下是对AnalyticDB产品使用合集的概述，包括数据导入、查询分析、数据管理、运维监控、扩展功能等方面。
真的很搞笑
260 1
嘟嘟嘟嘟嘟嘟
|
SQL 关系型数据库 MySQL
实时计算 Flink版产品使用合集之同步MySQL时，发现Timestamp字段少八个小时，该如何解决
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架，广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器，提供了一套全面的解决方案，以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点，使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
嘟嘟嘟嘟嘟嘟
415 7

热门文章

最新文章

  • 1
    MySQL数字类型int与tinyint、float与decimal如何选择
  • 2
    C++中int int& int * int**的区别、联系和用途
  • 3
    PHP 中，使用 (int) 或者 intval() 函数可以将变量转换为整数类型，区别是什么？底层原理是什么？
  • 4
    C++中int转为string
  • 5
    主键设置，总的来说int&gt;Guid/string
  • 6
    关于Int自增字段和GUID字段的性能测试。只有测试，没有分析，呵呵
  • 7
    C# 字节数组与INT16,float,double之间相互转换，字符数组与字符串相互转换，
  • 8
    int/double/string使用
  • 9
    POJ1068 Parencodings【用一个int变量作为栈】
  • 10
    【Android NDK 开发】JNI 方法解析 ( int 数组传递 | jintArray 类型 | 数组转换 | 获取数组长度 | 获取数组元素 | 指针遍历数组 | 数组返回值设置 )（二）
  • 1
    Python 操作 MySQL 数据库
    237
  • 2
    MySQL in 太慢的 3 种优化方案
    2645
  • 3
    MySQL函数
    148
  • 4
    AnalyticDB MySQL新购页面融合升级，提供企业版购买选项
    532
  • 5
    Mysql 数据库基本操作
    158
  • 6
    POLARDB：新零售用户MySQL上云最佳选择
    578
  • 7
    MySQL (索引 & 事务)
    156
  • 8
    MySQL索引
    102
  • 9
    MySQL事务
    110
  • 10
    MySQL表的进阶知识（下）
    144

    • 相关课程

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

    • 相关电子书

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

    • 推荐镜像

    更多
  • mysql
    • 下一篇
    「直播预告」Streaming Lakehouse Meetup EP.2｜Paimon × StarRocks 共话实时湖仓