Php 的 time() VS MySQL 的 UNIT_TIMESTAMP() 在 WHERE 子句中 - 哪个更快?
Php's time() VS MySQL's UNIT_TIMESTAMP() in WHERE clause - which is faster?
如有错误请指正:
所以情况是这样的。让我们想象一下对网站的大量查询 MySQL,有很多请求。而MySQL tables可以在写的过程中LOCK,所以其他用户就得等了。
另外据我所知,WHERE 子句中的 MySQL 函数在每一行(?)上呈现,因此它不会减慢查询速度。
虽然 Php 的 time() 就像一个静态数字,对于每次页面加载,它不会更新,也不需要在每次 time() 调用时重新计算(我相信它在 Php 内核的根 C/C++ 类 作为静态变量(?)。
我也知道如果我会使用:
WHERE table_field < '".(time()-86400)."'
它将在 MySQL 查询之前对 Php 页面加载进行减法计算,并且只会计算一次结果,
但如果我使用:
WHERE table_field < ".time()."-86400
然后它会对每一行进行计算。还是我错了 MySQL 对相同的计算值进行缓存?
场景: 我有 5M 行 长度 MySQL InnoDB table 命名为 bookings ,将 INDEXes 添加到 booking_id,booking_status, 付费, booking_timestamp 字段.
问题:我说得对吗,B 比 A 快得多:
A - 慢,MySQL timestamp():
-- Delete Expired bookings
DELETE FROM bookings WHERE booking_paid='0' AND booking_timestamp < (UNIX_TIMESTAMP()-86400)
B - 快,PHP的时间():
-- Delete Expired bookings
DELETE FROM bookings WHERE booking_paid='0' AND booking_timestamp < '".(time() - 86400)."'
QUESTION #2: 这种字段减法的情况如何:
-- Delete Expired bookings
DELETE FROM bookings b
JOIN payment_methods pm ON b.payment_type=pm.method_code
WHERE b.booking_paid='0' AND b.booking_timestamp < (UNIX_TIMESTAMP()-pm.unpaid_booking_expiration_time)
对比:
-- Delete Expired bookings
DELETE FROM bookings b
JOIN payment_methods pm ON b.payment_type=pm.method_code
WHERE b.booking_paid='0' AND b.booking_timestamp < (".time()."-pm.unpaid_booking_expiration_time)
对于这种确切情况,请尽可能深入地回答。
- SQL 中函数调用和表达式求值(例如减法)的成本与查找要处理的行的成本相比微不足道。
- 如果您的网页达到数千行,您需要重新设计架构 and/or 数据流。
- 使用 InnoDB(用于其行锁定)而不是 MyISAM(具有 table 锁定)。
- 函数只计算一次:
如此处所示
mysql> SELECT UNIX_TIMESTAMP(), SLEEP(2), UNIX_TIMESTAMP();
+------------------+----------+------------------+
| UNIX_TIMESTAMP() | SLEEP(2) | UNIX_TIMESTAMP() |
+------------------+----------+------------------+
| 1439708367 | 0 | 1439708367 |
+------------------+----------+------------------+
mysql> SELECT NOW(6), SLEEP(2), NOW(6);
+----------------------------+----------+----------------------------+
| NOW(6) | SLEEP(2) | NOW(6) |
+----------------------------+----------+----------------------------+
| 2015-08-16 00:05:38.941711 | 0 | 2015-08-16 00:05:38.941711 |
+----------------------------+----------+----------------------------+
如有错误请指正: 所以情况是这样的。让我们想象一下对网站的大量查询 MySQL,有很多请求。而MySQL tables可以在写的过程中LOCK,所以其他用户就得等了。 另外据我所知,WHERE 子句中的 MySQL 函数在每一行(?)上呈现,因此它不会减慢查询速度。 虽然 Php 的 time() 就像一个静态数字,对于每次页面加载,它不会更新,也不需要在每次 time() 调用时重新计算(我相信它在 Php 内核的根 C/C++ 类 作为静态变量(?)。 我也知道如果我会使用:
WHERE table_field < '".(time()-86400)."'
它将在 MySQL 查询之前对 Php 页面加载进行减法计算,并且只会计算一次结果, 但如果我使用:
WHERE table_field < ".time()."-86400
然后它会对每一行进行计算。还是我错了 MySQL 对相同的计算值进行缓存?
场景: 我有 5M 行 长度 MySQL InnoDB table 命名为 bookings ,将 INDEXes 添加到 booking_id,booking_status, 付费, booking_timestamp 字段.
问题:我说得对吗,B 比 A 快得多:
A - 慢,MySQL timestamp():
-- Delete Expired bookings
DELETE FROM bookings WHERE booking_paid='0' AND booking_timestamp < (UNIX_TIMESTAMP()-86400)
B - 快,PHP的时间():
-- Delete Expired bookings
DELETE FROM bookings WHERE booking_paid='0' AND booking_timestamp < '".(time() - 86400)."'
QUESTION #2: 这种字段减法的情况如何:
-- Delete Expired bookings
DELETE FROM bookings b
JOIN payment_methods pm ON b.payment_type=pm.method_code
WHERE b.booking_paid='0' AND b.booking_timestamp < (UNIX_TIMESTAMP()-pm.unpaid_booking_expiration_time)
对比:
-- Delete Expired bookings
DELETE FROM bookings b
JOIN payment_methods pm ON b.payment_type=pm.method_code
WHERE b.booking_paid='0' AND b.booking_timestamp < (".time()."-pm.unpaid_booking_expiration_time)
对于这种确切情况,请尽可能深入地回答。
- SQL 中函数调用和表达式求值(例如减法)的成本与查找要处理的行的成本相比微不足道。
- 如果您的网页达到数千行,您需要重新设计架构 and/or 数据流。
- 使用 InnoDB(用于其行锁定)而不是 MyISAM(具有 table 锁定)。
- 函数只计算一次:
如此处所示
mysql> SELECT UNIX_TIMESTAMP(), SLEEP(2), UNIX_TIMESTAMP();
+------------------+----------+------------------+
| UNIX_TIMESTAMP() | SLEEP(2) | UNIX_TIMESTAMP() |
+------------------+----------+------------------+
| 1439708367 | 0 | 1439708367 |
+------------------+----------+------------------+
mysql> SELECT NOW(6), SLEEP(2), NOW(6);
+----------------------------+----------+----------------------------+
| NOW(6) | SLEEP(2) | NOW(6) |
+----------------------------+----------+----------------------------+
| 2015-08-16 00:05:38.941711 | 0 | 2015-08-16 00:05:38.941711 |
+----------------------------+----------+----------------------------+