为什么WordPress的get_results比phpMyAdmin慢得多？

Question

背景/设置

我工作过的WordPress内置的Web应用程序跟踪，并基于测试数据的报告。我使用高级自定义字段（ACF）创建所有测试字段，并将它们存储在WP的默认wp_postmeta表中。这里的主要限制是表的键 - >值对 - ACF“repeater”字段（基本上是一个数据数组）与指向数组名，位置和任何子数组键的键一起存储为一个字符串）。

当保存和检索我需要的数据时，ACF刚刚杀死了我的应用程序速度，所以我编写了一些MySQL查询，使用WP的$wpdb->get_results函数直接从数据库中获取数据。

的问题

运行在WP的$wpdb->get_results有点复杂的MySQL的语句是不是通过phpMyAdmin的运行相同显著慢。

查询

SELECT ID as part_id, post_title as part_title, 
    GROUP_CONCAT(m2.meta_value ORDER BY m2.meta_key DESC SEPARATOR ', ') as part_name 
FROM `wp_postmeta` m 
JOIN wp_posts part  ON part.ID = m.meta_value 
JOIN wp_postmeta m2  ON m2.post_id = m.meta_value 
WHERE part.ID  = m.meta_value 
    AND m2.post_id = m.meta_value 
    AND m.meta_key LIKE 'participants_%_participant' 
    AND m.post_id = '51911' 
    AND post_type = 'participant' 
    AND post_status = 'publish' 
    AND (
     m2.meta_key = 'first_name' 
     OR m2.meta_key = 'last_name' 
    ) 
GROUP BY ID 
ORDER BY post_title 

更多详细信息

在phpMyAdmin，查询执行在不到一秒钟。通过get_results，它超时了我的页面。

我已经消除了所有其他代码问题，只在PHP页面上运行此查询（结果print_r，但页面超时首先）。

错误日志验证工作和记录，但没有错误从脚本记录。

wp_postmeta has this structure。

作为一个具体的DB片断例如：

meta_id | post_id|   meta_key   | meta_value 
305361 | 5713 | participants_0_participant | 14444 
305362 | 5191 | participants_0_participant | 14445 
305363 | 5890 | participants_0_participant | 14446 
305364 | 14444 | first_name     | Joe 
/* 
    `5191` is the class ID that the test is related to 
    `*_0` refers to the participant position in the participants array 
    `14444` is the participant unique ID 
8/ 

类和参加者post_types - 他们都有wp_posts table条目。

php.ini文件包括（验证为通过设置的phpinfo（））

memory_limit = 2048M 
max_execution_time = 1000 
set_time_limit = 1000 

我知道这数据库结构是根本不适合这种应用（这让我哭了一点点在里面）。将来它会转变成一个更合理的设置，但现在我只是想确定是否有一个可以很快修复的难以控制的缓慢原因。

Answer 1

如果你真的很好奇，你可以take a look！

根据你想从查询回来的东西，该函数将标准化输出，并重新格式化。这涉及到循环结果和建立新的产出结构，从而导致处理惩罚。

因为你关心的是性能，你可以利用直接query()方法和旁路额外的处理：

$results = $wbdp->query("your query goes here"); 

参考：http://codex.wordpress.org/Class_Reference/wpdb#Running_General_Queries

只是要小心，不引入通过这种方法潜在的SQL注入攻击。

Answer 2

的一种方式，加快涉及wp_postmeta是在这里采取的建议所有查询（？）：

http://mysql.rjweb.org/doc.php/index_cookbook_mysql#speeding_up_wp_postmeta

它讨论了一个更好的模式，在分度特别是改善。