8.2.1.18 函数调用优化
MySQL 函数在内部被标记为确定性或不确定性。如果给定参数固定值的函数可以为不同的调用返回不同的结果，则它是不确定的。非确定性函数的示例：RAND()，UUID()。
如果一个函数被标记为不确定的，则对WHERE子句中的每一行(从一个 table 中选择时)或行组合(从多 table 联接中选择时)的引用进行评估。
MySQL 还根据参数的类型(参数是 table 列还是常量值)确定何时评估函数。每当 table 列更改值时，都必须评估将 table 列作为参数的确定性函数。
非确定性函数可能会影响查询性能。例如，某些优化可能不可用，或者可能需要更多锁定。以下讨论使用RAND()，但也适用于其他不确定性函数。
假设 tablet具有以下定义：
CREATE TABLE t (id INT NOT NULL PRIMARY KEY, col_a VARCHAR(100));
考虑以下两个查询：
SELECT * FROM t WHERE id = POW(1,2);
SELECT * FROM t WHERE id = FLOOR(1 + RAND() * 49);
由于与主键的相等性比较，两个查询似乎都使用了主键查找，但这仅适用于第一个查询：
-
第一个查询始终最多产生一行，因为带有常量参数的POW()是常量值，用于索引查找。
-
第二个查询包含一个使用不确定函数RAND()的 table 达式，该函数在查询中不是常量，但实际上对于 table
t的每一行都有一个新值。因此，查询将读取 table 的每一行，评估每一行的谓词，并输出主键与随机值匹配的所有行。这可能是零行，一行或多行，具体取决于id列的值和RAND()序列中的值。
不确定性的影响不仅限于SELECT语句。此UPDATE语句使用非确定性函数来选择要修改的行：
UPDATE t SET col_a = some_expr WHERE id = FLOOR(1 + RAND() * 49);
大概的目的是最多更新主键与 table 达式匹配的一行。但是，它可能更新零，一或多个行，具体取决于id列的值和RAND()序列中的值。
刚刚描述的行为对性能和复制有影响：
-
由于不确定函数不会产生恒定值，因此优化器无法使用其他可能适用的策略，例如索引查找。结果可能是 table 扫描。
-
InnoDB可能升级为范围键锁定，而不是为一个匹配的行获取单个行锁定。 -
无法确定执行的更新对于复制是不安全的。
困难源于对 table 的每一行都对RAND()函数进行一次评估的事实。为了避免进行多功能评估，请使用以下技术之一：
- 将包含不确定性函数的 table 达式移到单独的语句，将值保存在变量中。在原始语句中，将 table 达式替换为对变量的引用，优化器可以将该变量视为常量值：
SET @keyval = FLOOR(1 + RAND() * 49);
UPDATE t SET col_a = some_expr WHERE id = @keyval;
- 将随机值分配给派生 table 中的变量。此技术使变量在
WHERE子句中的比较中使用之前被分配一个值：
SET optimizer_switch = 'derived_merge=off';
UPDATE t, (SELECT @keyval := FLOOR(1 + RAND() * 49)) AS dt
SET col_a = some_expr WHERE id = @keyval;
如前所述，WHERE子句中的不确定性 table 达式可能会阻止优化并导致 table 扫描。但是，如果其他 table 达式是确定性的，则可以部分优化WHERE子句。例如：
SELECT * FROM t WHERE partial_key=5 AND some_column=RAND();
如果优化器可以使用partial_key来减少所选行的集合，则执行RAND()的次数将减少，从而减少了不确定性对优化的影响。
