Как использовать, если условие для изменения $ table_prefix в wp_config.php

Я тестирую очень большую базу данных (возможно, wp_posts содержит сотни тысяч строк). Таким образом, время запроса, особенно поисковый запрос, чрезвычайно велико. Я думаю, если есть другой способ разбить базу данных WP на несколько таблиц с различным префиксом таблицы, чтобы структура URL-адресов не изменилась по сравнению с исходной базой данных.

Я попытался изменить $table_prefix в wp_config на wpa_ , после чего я создал пример сообщений с начальным именем, начинающимся с. Затем я изменил $table_prefix в wp_config на wpb_ , затем я создал пример сообщений с начальным именем, начинающимся с b .

На следующем шаге я $table_prefix строку $table_prefix на

 // if query for post start with a, it will go to wpa_ tables, // if query for post start with b, it will go to wpb_ tables $prefix = get_the_title(); if ($prefix(0) !== 'a') { $table_prefix = 'wpb_'; } else { $table_prefix = 'wpa_'; } 

Когда я попытался открыть мой домен, я получил ошибку. Fatal error: Call to undefined function get_the_title() in /home/todaytra/public_html/1/wp-config.php on line 62

Мне действительно нужно выполнить эту задачу, обычная установка WPMU генерирует либо поддомены, либо подпапки, и она изменяет структуру постоянных ссылок всех сообщений. Я много искал, но не могу найти информацию об этом.

Pam,

Похоже, вы столкнулись с некоторыми серьезными проблемами, но я бы очень рекомендовал не вмешиваться в префикс таблицы. Это приведет к ряду проблем, которые потребуют взлома после взлома, чтобы избавить вас от существенного беспорядка в установке WordPress.

Есть несколько других вещей, которые вы можете сделать, чтобы помочь решить проблемы с медленными запросами. Хотя эти вещи не все обязательно прямые, они больше стоят вашего времени, чем пытаться взломать префикс таблицы.

1) Убедитесь, что вы находитесь на WP 3.4+. В 3.4 были улучшены стандартные запросы, улучшающие скорость запросов.

2) Для особенно проблемных запросов рассмотрите возможность установки no_found_rows на true , update_post_term_cache на false и update_post_meta_cache на false . Все это может привести к повышению производительности запросов, но вам определенно нужно потратить некоторое время на понимание последствий. Читайте о них в Codex: http://codex.wordpress.org/Class_Reference/WP_Query

3) Используйте кеш постоянной памяти для обеспечения кэширования запросов. Это определенно более сложный процесс, но, кэшируя дорогостоящие запросы к ОЗУ или диску, вы можете сохранять повторяющиеся медленные запросы.

4) Установите кеш страницы ( WP Super Cache делает это хорошо), что поможет уменьшить количество вызовов дорогого запроса. Это напрямую не касается проблемы с запросом; однако он уменьшает количество запросов, которые могут быть вызваны.

Помимо первого предложения, я не считаю, что любой из них «прост»; однако то, что вы предлагаете сделать, было бы гигантской тратой, на мой взгляд, и ваше время было бы лучше потрачено на изучение альтернативных вариантов решения медленных запросов в WordPress. Вы узнаете больше о WordPress, проблемах масштабируемости и лучших способах делать вещи в стандартном стиле WordPress.