Laravel 默认不创建 broadcast_events 表，因其广播机制不落库，仅通过 Redis、Pusher 等第三方服务传输事件；若需日志需手动建表并监听 BroadcastEvent 事件。
查不到 broadcast_events 表？Laravel 默认不建这个表
PHPMyAdmin 里找不到 broadcast_events 或类似表名，不是你漏刷了，是 Laravel 根本不自动创建它。Laravel 的广播（Broadcasting）本身不落库——它只负责把事件推给 Pusher、Redis、Ably 这类服务，数据生命周期在内存或第三方通道里。
如果你看到某些项目里有 pusher_events 或 broadcast_logs 表，那一定是开发者自己加的日志逻辑，不是框架行为。
- 检查你的
App\Providers\BroadcastServiceProvider，确认没手动写入数据库的监听器 - 搜索代码里有没有对
DB::table('...')->insert()或 Eloquent 模型操作，尤其在BroadcastEvent相关的监听器或中间件中 - 运行
php artisan tinker，执行DB::select("SHOW TABLES LIKE 'broadcast%'")，验证是否真有这张表
Redis 作为广播驱动时，怎么用 PHPMyAdmin 查？根本查不了
PHPMyAdmin 是 MySQL/MariaDB 管理工具，而 Laravel 广播若用 redis 驱动（默认配置），所有广播数据都存在 Redis 里，和数据库完全无关。你在 PHPMyAdmin 里翻遍所有表也看不到任何广播内容。
要排查这类广播，得换工具：
立即学习“PHP免费学习笔记（深入）”；
- 用
redis-cli连上对应 Redis 实例，执行KEYS *broadcast*或PUBSUB CHANNELS *broadcast* - 如果用了 Redis Streams（Laravel 10+ 可选），查
XREAD GROUP对应的 stream 名，比如laravel_database_broadcasts - 确认
BROADCAST_CONNECTION=redis在.env中，且config/broadcasting.php里redis配置指向正确 DB 和 host
想持久化广播日志？得自己加表 + 监听 BroadcastEvent
如果业务真需要存广播记录（比如审计、重放、调试），Laravel 提供了 Illuminate\Events\BroadcastEvent 事件，你可以在 EventServiceProvider 里监听它并写入自定义表。
典型做法：
- 先运行
php artisan make:migration create_broadcast_logs_table，建表包含event_name、data（JSON）、connection、created_at - 在
app/Listeners/LogBroadcastEvent.php里序列化$event->event和$event->socket - 注意：不要在监听器里做耗时操作，否则阻塞广播；建议 dispatch 到
database队列异步处理 -
data字段推荐用JSON类型（MySQL 5.7+），别用TEXT后手工 json_encode
常见误判：把队列失败表当广播表
很多人在 PHPMyAdmin 里看到 failed_jobs 表，以为里面是广播失败记录——其实不是。failed_jobs 只存通过 dispatch() 推进队列的任务，而广播事件本身不走队列（除非你显式调用 onQueue()）。
如果你的广播触发了队列任务（比如广播后发邮件），那失败的是那个邮件任务，不是广播本身。
- 检查
config/broadcasting.php的connections.redis.options.scan是否设错，导致频道订阅失败但无报错 - 看 Laravel 日志里有没有
Unable to connect to Redis或Pusher error: 401，这类才是广播失败的真正线索 - 浏览器控制台 Network 标签页查
/broadcasting/auth请求状态，403/500 比数据库更早暴露问题
