php无法设置表过期时间，mysql不支持表级ttl；需通过expires_at字段+定时任务或event清理过期记录，并在应用层读写时校验时间有效性。
PHP 本身不提供“设置表过期时间”的功能——数据库表没有内置 TTL（Time-To-Live）机制，所谓“过期表”必须靠外部逻辑实现。
MySQL 表数据自动过期的常见做法
真正需要的是让表中**某些记录在指定时间后失效或被清理**，而不是让整个表消失。典型场景是缓存表、临时订单、验证码、会话日志等。
-
CREATE TABLE时不支持EXPIRE_AT或类似语法（MySQL 8.0+ 的REPLICATION或INFORMATION_SCHEMA也不管这个） - 必须依赖字段（如
expires_atDATETIME） + 定时任务（crontab+ PHP 脚本）或 MySQL 事件（EVENT） - 应用层每次读取前应校验
expires_at ，避免返回已过期数据
CREATE TABLE user_tokens (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
token VARCHAR(255) NOT NULL,
user_id INT NOT NULL,
expires_at DATETIME NOT NULL,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
<p>-- 查询时过滤过期项
SELECT * FROM user_tokens WHERE user_id = 123 AND expires_at > NOW();</p>用 MySQL EVENT 实现自动清理
适合低频写入、容忍分钟级延迟的场景。注意：MySQL 服务需开启 event_scheduler=ON，且用户有 EVENT 权限。
- 事件不能触发外部脚本，仅限 SQL 操作（如
DELETE） - 不适用于需要复杂业务逻辑（如发通知、更新关联状态）的过期处理
- 调试困难，错误日志分散在 MySQL 错误日志中，不易追踪
SET GLOBAL event_scheduler = ON; <p>CREATE EVENT cleanup_expired_tokens ON SCHEDULE EVERY 1 HOUR DO DELETE FROM user_tokens WHERE expires_at < NOW();</p>
PHP 中控制过期逻辑的要点
不要只依赖数据库定时清理，应用层必须主动判断过期——否则可能读到刚被插入但尚未过期、却即将被删的数据，或因事件延迟导致脏读。
![PHP房产程序[BBWPS]](https://img.php.cn/upload/webcode/000/000/017/176518440895337.jpg)
PHP房产程序[BBWPS]
下载
[PHP房产程序|BBWPS]功能介绍 1、5种信息类别发布：出租、求租、出售、求购、楼盘信息,支持会员发布信息审核； 2、灵活的信息参数设置； 3、充足的信息字段； 4、简单易用的发布/编辑功能，支持配图上传； 5、灵活的信息管理功能； 6、信息输出伪静态，方便搜索引擎抓取数据； 7、支持RSS输出； 8、内置数据高速缓冲技术，可灵活设置缓冲功能是否启动及过期时间； 9、支持 Google 地图
立即学习“PHP免费学习笔记（深入）”；
- 写入时统一设置
expires_at：用date('Y-m-d H:i:s', time() + 3600)而非NOW()，避免时区/服务器时间偏差 - 读取时强制加条件：
WHERE expires_at > ?，参数绑定当前时间戳（date('Y-m-d H:i:s')） - 删除操作建议软删（加
is_expired TINYINT(1) DEFAULT 0）+ 异步清理，避免大表DELETE锁表 - Redis 更适合作为带 TTL 的临时存储；若坚持用 MySQL，可考虑
TTL字段 + 应用层兜底
为什么不能直接“让表过期”
表是数据库对象，其生命周期由 DDL（DROP TABLE）控制。没有任何主流 RDBMS 支持“创建一个表，N 小时后自动销毁”。强行实现只会引入严重风险：
- 误删：脚本出错或时间计算偏差导致核心表被
DROP - 权限失控：执行
DROP需要高权限，不符合最小权限原则 - 无回滚：DDL 不在事务中，不可回退
- 影响 DDL 同步：主从复制、备份工具可能无法正确处理动态表结构变更
真正要管的不是“表”，而是“数据的有效性边界”——把过期逻辑沉到字段、查询条件和清理策略里，比幻想自动删表靠谱得多。
