Mysql

关注公众号 jb51net

关闭
首页 > 数据库 > Mysql > MySQL函数sysdate now区别

MySQL函数sysdate()与now()的区别测试用例对比

作者:爱可生开源社区

这篇文章主要为大家介绍了MySQL函数sysdate()与now()的区别测试用例对比详解,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步,早日升职加薪

背景

在客户现场优化一批监控 SQL 时,发现一批 SQL 使用 sysdate() 作为统计数据的查询范围值,执行效率十分低下,查看执行计划发现不能使用到索引,而改为 now() 函数后则可以正常使用索引,以下是对该现象的分析。

内心小 ps 一下:sysdate() 的和 now() 的区别这是个⽼问题了。

函数 sysdate 与 now 的区别

下面我们来详细了解一下函数 sysdate() 与 now() 的区别,我们可以去官方文档 查找他们两者之间的详细说明。

根据官方说明如下:

下面我们通过官方提供的案例直观展现两者区别。

mysql> SELECT NOW(), SLEEP(2), NOW();
+---------------------+----------+---------------------+
| NOW()               | SLEEP(2) | NOW()               |
+---------------------+----------+---------------------+
| 2023-12-14 15:13:09 |        0 | 2023-12-14 15:13:09 |
+---------------------+----------+---------------------+
1 row in set (2.00 sec)
mysql> SELECT SYSDATE(), SLEEP(2), SYSDATE();
+---------------------+----------+---------------------+
| SYSDATE()           | SLEEP(2) | SYSDATE()           |
+---------------------+----------+---------------------+
| 2023-12-14 15:13:19 |        0 | 2023-12-14 15:13:21 |
+---------------------+----------+---------------------+
1 row in set (2.00 sec)

通过上面的两条 SQL 我们可以发现,当 SQL 语句两次调用 now() 函数时,前后两次 now() 函数返回的是相同的时间,而当 SQL 语句两次调用 sysdate() 函数时,前后两次 sysdate() 函数返回的时间在更新。

到这里我们根据官方文档的说明加上自己的推测大概可以知道,函数sysdate() 之所以不能使用索引是因为 sysdate() 的不确定性导致索引不能用于评估引用它的表达式。

测试示例

以下通过示例模拟客户类似场景。

我们先创建⼀张测试表,对 create_time 字段创建索引并插入数据,观测函数 sysdate() 和 now() 使⽤索引的情况。

mysql> create table t1(
    ->   id int primary key auto_increment,
    ->   create_time datetime default current_timestamp,
    ->   uname varchar(20),
    ->   key idx_create_time(create_time)
    -> );
Query OK, 0 rows affected (0.02 sec)
mysql> insert into t1(id) values(null),(null),(null);
Query OK, 3 rows affected (0.01 sec)
Records: 3  Duplicates: 0  Warnings: 0
mysql> insert into t1(id) values(null),(null),(null);
Query OK, 3 rows affected (0.00 sec)
Records: 3  Duplicates: 0  Warnings: 0
mysql> select * from t1;
+----+---------------------+-------+
| id | create_time         | uname |
+----+---------------------+-------+
|  1 | 2023-12-14 15:34:30 | NULL  |
|  2 | 2023-12-14 15:34:30 | NULL  |
|  3 | 2023-12-14 15:34:30 | NULL  |
|  4 | 2023-12-14 15:34:37 | NULL  |
|  5 | 2023-12-14 15:34:37 | NULL  |
|  6 | 2023-12-14 15:34:37 | NULL  |
+----+---------------------+-------+
6 rows in set (0.00 sec)

先来看看函数 sysdate() 使⽤索引的情况。可以发现 possible_keys 和 key 均为 NULL,确实使⽤不了索引。

mysql> explain select * from t1 where create_time<sysdate()\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: t1
   partitions: NULL
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 6
     filtered: 33.33
        Extra: Using where
1 row in set, 1 warning (0.00 sec)

再来看看函数 now() 使⽤索引的情况,可以看到 key 使⽤到了 idx_create_time 这个索引。

mysql> explain select * from t1 where create_time<now()\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: t1
   partitions: NULL
         type: range
possible_keys: idx_create_time
          key: idx_create_time
      key_len: 6
          ref: NULL
         rows: 6
     filtered: 100.00
        Extra: Using index condition
1 row in set, 1 warning (0.00 sec)

示例详解

下面我们进一步通过 trace 去分析优化器对于函数 now() 和 sysdate() 具体是如何去优化的。

函数 sysdate() 部分关键 trace 输出

"rows_estimation": [                  
## 估算使用各个索引进行范围扫描的成本
    {
      "table": "`t1`",
      "range_analysis": {
        "table_scan": {
          "rows": 6,
          "cost": 2.95
        },
        "potential_range_indexes": [
          {
            "index": "PRIMARY",
            "usable": false,
            "cause": "not_applicable"
          },
          {
            "index": "idx_create_time",
            "usable": true,
            "key_parts": [
              "create_time",
              "id"
    ............................................
        "setup_range_conditions": [
        ],
        "group_index_range": {
          "chosen": false,
          "cause": "not_group_by_or_distinct"
        },
        "skip_scan_range": {
          "chosen": false,
          "cause": "disjuntive_predicate_present"
        }
    ............................................
  "considered_execution_plans": [       
  ## 对比各可行计划的代价,选择相对最优的执行计划
    {
      "plan_prefix": [
      ],
      "table": "`t1`",
      "best_access_path": {
        "considered_access_paths": [
          {
            "rows_to_scan": 6,
            "access_type": "scan",
            "resulting_rows": 6,
            "cost": 0.85,
            "chosen": true
          }
        ]
      },
      "condition_filtering_pct": 100,
      "rows_for_plan": 6,
      "cost_for_plan": 0.85,
      "chosen": true
    ............................................

函数 now() 部分关键 trace 输出

"rows_estimation": [                  
## 估算使用各个索引进行范围扫描的成本
  ............................................
      "analyzing_range_alternatives": {
        "range_scan_alternatives": [
          {
            "index": "idx_create_time",
            "ranges": [
              "NULL < create_time < '2023-12-14 15:48:39'"
            ],
            "index_dives_for_eq_ranges": true,
            "rowid_ordered": false,
            "using_mrr": false,
            "index_only": false,
            "in_memory": 1,
            "rows": 6,
            "cost": 2.36,
            "chosen": true
          }
        ],
  ............................................
      },
      "chosen_range_access_summary": {
        "range_access_plan": {
          "type": "range_scan",
          "index": "idx_create_time",
          "rows": 6,
          "ranges": [
            "NULL < create_time < '2023-12-14 15:48:39'"
          ]
        },
        "rows_for_plan": 6,
        "cost_for_plan": 2.36,
        "chosen": true
 .............................................
 "considered_execution_plans": [      
 ## 对比各可行计划的代价,选择相对最优的执行计划                            
  {
    "plan_prefix": [
    ],
    "table": "`t1`",
    "best_access_path": {
      "considered_access_paths": [
        {
          "rows_to_scan": 6,
          "access_type": "range",
          "range_details": {
            "used_index": "idx_create_time"
          },
          "resulting_rows": 6,
          "cost": 2.96,
          "chosen": true
        }
      ]
    },
    "condition_filtering_pct": 100,
    "rows_for_plan": 6,
    "cost_for_plan": 2.96,
    "chosen": true
 .............................................

通过上述 trace 输出,我们可以发现对于函数 now(),优化器在 rows_estimation 时即估算使用各个索引进行范围扫描的成本这一步时可以将 now() 的值转换为一个常量,最终在 considered_execution_plans 这一步去对比各可行计划的代价,选择相对最优的执行计划。而通过函数 sysdate() 时则无法做到该优化,因为 sysdate() 是动态获取的时间。

总结

通过实际验证执行计划和 trace 记录并结合官方文档的说明,我们可以做以下理解。

以上就是MySQL函数sysdate()与now()的区别测试用例对比的详细内容,更多关于MySQL函数sysdate now区别的资料请关注脚本之家其它相关文章!

您可能感兴趣的文章:
阅读全文