Как обычный представитель подвида btree индексов для range поиска. Поиском от корня находим нужный MarketName, идём до минимальной подходящей даты и вычитываем все узлы до максимальной подходящей. С полученными id лезем в primary key и вычитываем непосредственно данные таблицы (т.к. innodb всегда кластеризован по первичному ключу и все вторичные индексы ссылаются на PK, а не на расположение данных в датафайлах)
Я проголосовал за изменение сложности вопроса на senior. exit, echo - не функции, а конструкции языка. Поэтому это где-то в потрохах Zend движка языка. Возможно глубоко в потрохах.
Вероятно у вас где-то до этого файла объявлялись такие константы. Вообще странная мысль делать константы с текстом регулярок с такими именами в глобальном пространстве имён.
Несортированным списком: mysql, postgresql, oracle, mssql.
Вот sqlite dba я себе как-то не представляю. Самая распространённая субд, но не серверная и базы у неё очень маленькие и потому проблем не дают.
Что востребовано смотрите вакансии. Интересные проекты есть для всех этих 4 СУБД, а я не изучал реалии трудового рынка DBA.
Следовательно, вы не перезагрузились. Если под "перезагрузился" вы подразумевали reload - то значит не проверили логи базы, там было извещение о том, что изменение параметра не применено, т.к. требует рестарта..
Уточнение обозначает, что изменение этого параметра возможно только при старте базы. На живую не изменить.
Ну и надеюсь вы параметр всё-таки раскомментировали.
Разделять запись от чтения правильнее именно на приложении. Потому что именно приложение знает, будет ли операция что-то модифицировать и насколько критична актуальность данных. Может быть и 100% читающий запрос, который можно вызывать только на мастере. (например, потому что ставить ещё и синхронную реплику оказалось для проекта хуже)
1025 > 1024.
Можете проверить запросом show track_activity_query_size что настройка изменилась.
Возможно ваш GUI со своей стороны ограничивает.дополнительно вывод.
Поясните, я не понял зачем вам изменять процедуры при failover.
Для потоковой репликации все реплики являются идентичными мастеру, даже бинарно идентичными. С потоковой репликацией вы в принципе не можете сделать разные хранимки на мастере и слейвах. Разница только в том, что на слейве пишущая хранимка вернёт ошибку что невозможно что-то писать в readonly базе. И при failover мастера вам необходимо проинструктировать приложение о том, на какой хост необходимо отправлять пишущие запросы. Впрочем, это можно сделать силами например haproxy, который будет простым скриптом опрашивать хосты на select pg_is_in_recovery() - кто ответил false тот и есть мастер.
primary key - определяет уникальную строку. Про то, что он может быть из одного поля речи нет. Если уникальность задают два поля - то и PK будет состоять из двух полей.
Плюс два foreign key, т.к. это значения-ссылки и будет хорошо, если база сможет проверять существование строк, на которые вы ссылаетесь.
например одна только на передачу, вторая только на прием сигнала, и будет ли увеличение скорости (обе гигабитые)?
В таком виде не имеет смысла, гигабит бывает только полнодуплексный, т.е. возможен одновременно и приём и передача данных. Это 10 и 100мбит ethernet могли быть полудуплексными.
Так и нафига вам сдался STR_TO_DATE? Чтобы дату приводить к строке, потом пытаться ипользуя не тот формат строки привести обратно в дату и сравнивать с литералом, попутно отстрелив всякую возможность использовать индексы? created_at < STR_TO_DATE('01.01.2017', '%d.%m.%Y')
И как там, во времена SIMM?
DIMM могут работать не только парами. Попарно их ставят только ради небольшого преимущества в виде распространённого dual channel (плюс см 3 и 4 канальные контроллеры памяти)
