WordPress用户VIP权限不存于wp_users表，而是由会员插件通过关系表管理：MemberPress用mepr_subscriptions和mepr_transactions表，Paid Memberships Pro用wp_memberships表，自定义字段则存于wp_usermeta表。
WordPress 用户 VIP 权限存在哪张表里？
绝大多数主流会员插件（如 memberpress、restrict content pro、wp user manager + paid memberships pro）**不会直接在 wp_users 表里加 vip 字段**，而是用关系表记录订阅状态。你得先确认自己装的是哪个插件——查不到插件名，改错表就等于给用户发了张空气 vip 卡。
-
MemberPress：权限靠mepr_subscriptions和mepr_transactions联动，status = 'active'且product_id对应 VIP 产品才算生效 -
Paid Memberships Pro：核心是wp_memberships表，status = 'active'+membership_id指向 VIP 会员级别 ID - 纯自定义字段（比如用
update_user_meta()存的）：查wp_usermeta表，找meta_key类似vip_expires或is_vip的记录
手动更新 wp_usermeta 表解锁 VIP 的风险点
很多用户以为只要往 wp_usermeta 插一条 is_vip = 1 就完事，但实际会触发缓存不一致、插件钩子未执行、前端权限判断失效等问题——因为插件通常不监听这个字段变化，它只认自己维护的状态表。
- 插件启用「会员过期自动降级」时，
wp_usermeta里的值会被忽略，下次 cron 执行后立刻还原 - 部分插件（如
Restrict Content Pro）把权限绑定到rcp_subscription_id，改usermeta完全无效 - 如果用户已有其他活跃订阅，强行插入 VIP 字段可能造成状态冲突，后台显示「多个会员身份」但实际只生效一个
安全可靠的数据库直连操作步骤
真要绕过后台批量开 VIP，必须模拟插件自身的数据写入逻辑，而不是拍脑袋加字段。以 Paid Memberships Pro 为例：
INSERT INTO wp_memberships (user_id, membership_id, status, startdate, enddate) VALUES ( (SELECT ID FROM wp_users WHERE user_login = 'username'), 3, -- VIP 会员级别的 ID，去 wp_membership_levels 查 level_id 'active', NOW(), DATE_ADD(NOW(), INTERVAL 365 DAY) );
- 务必先查
wp_membership_levels确认 VIP 对应的id，别硬写 3 -
startdate和enddate必须用 MySQL 时间函数（如NOW()），不能填字符串'2025-01-01'，否则插件读取失败 - 操作前备份
wp_memberships表，这条 SQL 不会自动清理旧记录，重复执行会生成多条「active」状态，导致权限异常
为什么改完数据库前台还是没 VIP 样式？
数据库改对了，但用户访问时仍看不到 VIP 标识或专属内容，大概率是对象缓存（Redis / Memcached）或页面缓存（WP Super Cache / Cloudflare）没刷新。插件读取的是缓存里的用户对象，不是实时查库。
- 登录 WordPress 后台，进「WP Engine → Cache → Purge All Caches」（如果用 WP Engine）
- 命令行清空 Redis：
redis-cli FLUSHDB（注意不是FLUSHALL，避免清掉其他应用缓存） - 如果用了 OPcache，需重启 PHP-FPM 或执行
opcache_reset()（通过临时 PHP 文件） - 用户本人也得退出再登录一次，否则
wp_get_current_user()缓存未更新，current_user_can('access_vip_content')仍返回 false
最麻烦的其实是权限判断逻辑分散在多个地方：模板里用 pmpro_hasMembershipLevel()，REST API 里可能走另一个钩子，数据库改了只是起点，不是终点。
