WordPress 中的用户角色存储与查询前提
WordPress 数据库结构中，用户的权限和角色信息核心存放在 wp_users 与 wp_usermeta 两张表之间的关联关系中。具体来说，关于角色的关键信息保存在 meta_key 为 wp_capabilities 的记录里，而 meta_value 则是一个序列化的 PHP 数组，标识了该用户具备的角色。理解这一点是后续通过 SQL 查询筛选特定角色用户的基础。
多站点环境与表前缀是需要关注的现实要点。在多站点（Multisite）情形下，元数据中的键名可能被站点前缀和站点 ID 影响，导致实际的 meta_key 形如 wp_2_capabilities。因此，在编写 SQL 时，需要根据实际前缀来定位 meta_key，并在必要时对前缀进行模糊匹配。
完整示例：使用 SQL 查询特定角色的用户
基本实现：单站点、单角色
以下示例以默认前缀 wp_ 为前提，目标角色为 editor。通过将 wp_users 与 wp_usermeta 进行连接，并筛选 meta_key = 'wp_capabilities'、meta_value 含有 editor 的序列化片段即可得到符合条件的用户清单。
重要点在于：meta_key 需要与你站点的实际表前缀相匹配，meta_value 的序列化格式包含了角色标识字段，例如 \"editor\"，因此通常需要使用 LIKE 条件来匹配该片段。
-- 查询具有 editor 角色的用户（单站点，前缀为 wp_）
SELECTu.ID,u.user_login,u.user_email,u.display_name
FROMwp_users AS u
JOINwp_usermeta AS m ON m.user_id = u.ID
WHEREm.meta_key = 'wp_capabilities'AND m.meta_value LIKE '%"editor";%' -- editor 的序列化表示通常包含 "editor";说明：如果某些版本的序列化数据略有差异，可以同时使用两种匹配方式以提高兼容性，例如同时包含 %\"editor\"%; 以及 %s:6:\"editor\";% 的模式，但应避免误匹配其他文本。对于单角色用户，这种做法通常可以稳定工作。
进一步注意：如果一个用户具备多个角色（如 editor 与 administrator），其 meta_value 中会出现多组键值对。为了确保结果的去重与准确性，可以在查询中使用 DISTINCT 或者在应用层再做去重处理。
进阶示例：处理多角色用户与多站点前缀
在多站点环境下，meta_key 可能是类似 wp_2_capabilities 的形式，因此需要在 SQL 中针对具体站点进行筛选，或者用通用的模糊匹配来覆盖所有站点前缀的 capabilities 字段。
-- 多站点环境下，查询任意站点中具有 editor 角色的用户（使用模糊匹配 _capabilities）
SELECT DISTINCT u.ID, u.user_login, u.user_email, u.display_name
FROM wp_users AS u
JOIN wp_usermeta AS m ON m.user_id = u.ID
WHERE m.meta_key LIKE '%_capabilities'AND m.meta_value LIKE '%"editor";%' -- 兼容不同站点前缀下的 capabilities;另一个示例（指定站点 ID 的情况），如果你明确要查询站点 2 内的用户，可直接指向具体 meta_key，例如 wp_2_capabilities，后续筛选同上。
-- 指定站点 2 的编辑者
SELECT DISTINCT u.ID, u.user_login, u.user_email, u.display_name
FROM wp_users AS u
JOIN wp_usermeta AS m ON m.user_id = u.ID
WHERE m.meta_key = 'wp_2_capabilities'AND m.meta_value LIKE '%"editor";%';
注意事项
表前缀与多站点兼容性
请将 SQL 中的 wp_ 替换为实际的表前缀，该前缀在 WordPress 的 wp-config.php 中通过 $table_prefix 定义。不同站点可能拥有不同前缀，因此在生产环境中执行 SQL 时务必确认前缀的正确性，以避免查询不到数据。
多站点环境下的 meta_key 形式通常为 wp_#_capabilities，其中# 是站点 ID。若要覆盖全部站点，可以使用模糊匹配 m.meta_key LIKE '%_capabilities'，但需评估性能影响。
序列化数据的局限性与搜索效率
meta_value 的序列化数据不适合高效索引，LIKE 查询会对全表扫描产生较高成本，尤其是在用户数量较大的站点。若遇到性能瓶颈，考虑通过以下方式降低成本：
在数据库层的替代方案：采用具体的执行计划，限制筛选范围或分区查询，必要时对能力字段建立简化字段或映射表，将角色信息冗余到新表中以便快速查询。
安全性与数据备份考量
在对生产数据库执行查询前，务必完成备份并在只读模式下测试，以防意外修改导致数据不一致。此外，只有具备相应权限的用户才应执行涉及用户数据的查询操作。
多站点的替代查询场景与限制
在极大型站点或混合环境中，直接对 wp_usermeta 的 meta_value 进行模糊匹配可能影响性能。此时可以考虑先行筛选出可能包含目标角色的用户，再在应用层进行最终过滤，或通过 WP-CLI 等工具进行分批查询。
