Если есть сомнения, посмотрите на исходный код.
Копаясь в get_option()
, вы увидите (сокращенно):
$value = wp_cache_get( $option, 'options' );
if ( false === $value ) {
$row = $wpdb->get_row( $wpdb->prepare( "SELECT option_value FROM $wpdb->options WHERE option_name = %s LIMIT 1", $option ) );
// Has to be get_row instead of get_var because of funkiness with 0, false, null values
if ( is_object( $row ) ) {
$value = $row->option_value;
wp_cache_add( $option, $value, 'options' );
} else { // option does not exist, so we must cache its non-existence
$notoptions[$option] = true;
wp_cache_set( 'notoptions', $notoptions, 'options' );
return apply_filters( 'default_option_' . $option, $default );
}
}
Сначала WordPress проверяет, есть ли у него опция в памяти. По умолчанию wp_cache_get()
извлекает значения из хранилища данных в памяти (обычно это просто переменная PHP). Но некоторые установки используют более сложный объектный кеш, который хранит данные в другом месте.
В любом случае wp_cache_get()
вернет значение вашего параметра, если WordPress уже знает это.
Если нет, то WordPress попытается извлечь его из базы данных. Если опция существует в БД, WordPress кэширует ее в памяти, а затем возвращает обратно, что ускоряет последующий поиск.
Если этот параметр не существует в базе данных, WordPress помечает его во внутреннем массиве «эти параметры не существует», поэтому он не пытается найти его позже и возвращает вместо него некоторое значение по умолчанию.
Итак, чтобы ответить на ваш оригинальный вопрос:
Если я использую это 10 раз в различных функциях моего плагина, делает ли WordPress 10 запросов к базе данных, или он делает только 1 вызов базы данных на HTTP-запрос и кэширует результаты?
WordPress будет делать 1 вызов базы данных на HTTP-запрос и кэшировать результаты.