时间值作为UTC值存储在TIMESTAMP列中，插入TIMESTAMP栏和从TIMESTAMP栏内检索的值在会话时区和UTC之间转换。（这与CONVERT_TZ（）函数执行的转换类型相同。如果会话时区为UTC，则实际上没有时区转换。）
由于当地时区更改的惯例，如夏令时（DST），UTC和非UTC时区之间的转换在两个方向上不是一一对应的。不同的UTC值在另一个时区可能不不同。以下示例显示了在非UTC时区中变得相同的不同UTC值：
您可以看到，当转换为“MET”时区时，这两个不同的UTC值是相同的。对于给定的TIMESTAMP列查询，这种现象可能会导致不同的结果，具体取决于优化器是否使用索引来执行查询。
假设一个查询使用WHERE子句从前面显示的表中选择值，在ts列中搜索单个特定值，例如用户提供的时间戳文字：
进一步假设查询在以下条件下执行：
会话时区不是UTC，而是夏令时。例如：
由于夏令时偏移，存储在TIMESTAMP列中的唯一UTC值在会话时区中不是唯一的。（前面显示的示例说明了这是如何发生的。）
该查询指定了一个搜索值，该值在会话时区中进入夏令时的小时内。
在这些条件下，WHERE子句中的比较对于非索引和索引查找以不同的方式发生，并导致不同的结果：
如果没有索引或优化器无法使用它，则会在会话时区中进行比较。优化器执行表扫描，检索每个ts列值，将其从UTC转换为会话时区，并将其与搜索值（也在会话时区中解释）进行比较：
由于存储的ts值被转换为会话时区，因此查询可以返回两个与UTC值不同但在会话时区中相等的时间戳值：一个值发生在时钟更改时的夏令时转换之前，另一个值出现在夏令时切换之后。
如果有可用的索引，则以UTC进行比较。优化器执行索引扫描，首先将搜索值从会话时区转换为UTC，然后将结果与UTC索引条目进行比较：
在这种情况下，（转换后的）搜索值仅与索引条目匹配，并且由于不同存储的UTC值的索引条目也是不同的，因此搜索值只能匹配其中一个。
由于非索引和索引查找的优化器操作不同，查询在每种情况下都会产生不同的结果。非索引查找的结果返回会话时区中匹配的所有值。索引查找不能这样做：
它在存储引擎内执行，存储引擎只知道UTC值。
对于映射到相同UTC值的两个不同会话时区值，索引查找仅匹配相应的UTC索引条目，并仅返回一行。
在前面的讨论中，存储在tstable中的数据集恰好由不同的UTC值组成。在这种情况下，所有使用所示形式的索引查询最多只匹配一个索引条目。
如果索引不是唯一的，则表（和索引）可以存储给定UTC值的多个实例。例如，ts列可能包含UTC值“2018-10-28 00:30:00”的多个实例。在这种情况下，使用查询的索引将返回它们中的每一个（在结果集中转换为MET值'2018-10-28 02:30:00'）。使用索引的查询将转换后的搜索值匹配到UTC索引条目中的单个值，而不是匹配转换为会话时区中搜索值的多个UTC值，这仍然是正确的。
如果返回会话时区中匹配的所有ts值很重要，解决方法是使用IGNORE index提示禁止使用索引：
在其他情况下也会出现双向时区转换缺乏一对一映射的情况，例如使用FROM_UNIXTIME（）和UNIX_TIMESTAMP（）函数执行的转换。见第12.7节“日期和时间函数”。
