pwlnw

Однако, попробуй подцепить этот скрипт для mysql-proxy: github.com/clofresh/mysql-proxy-cache
разумеется он кеширует все игнорируя логику приложения.

Я плохо понимаю зачем может понадобиться такое решение.
Встроенным кешированием запросов можно управлять явно через ключевые слова SQL_CACHE и SQL_NO_CACHE.

«Прозрачное кеширование» есть в самом mysql.
Оно настолько хорошо и прозрачно работает, что ты про него даже не знаешь.
Проблема возникает тогда, когда нужно кеш инвалидировать. Например, обновление некоторых записей. Поэтому выдуманное тобой прозрачное кеширование вынуждено будет повторить поведение кеша mysql — удалить все запросы содержащие обновляемую таблицу. Ну и зачем писать то, что уже написано?

Отсюда вывод: если хочется что-то ускорить еще быстрее кеша mysql — кеширование не должно быть прозрачным. Для каждого оператора должно хотя бы указываться предположительное время жизни результата в кеше.

Теоретически, если в редакторе DNS создать MX-запись и указать localhost как обработчик почты, то почта и спам извне просто не придут.
Практически, ваши сайты могут рассылать почту, а письма-ошибки будут валиться в эти ящики.
И неадкватные спамеры могут отправлять почту прямо по А-записям то есть на тот же сервер, который обслуживает сайт.

И с каких это пор использование nosql стало удобненьким?
Терпи. Напиши два запроса.

>perl Makefile.PL
раз уж perl запускается до make, воспользуйтесь этим прекрасным платформонезависимым языком для определения подходящего префикса.

Вот первый попавшийся пример из DBD::Interbase
…
my $os = $Config::Config{'osname'};
if ($os eq 'MSWin32')
{… и дальше погнали в реестре ковыряться.

Судя по всему дело в кодировке. Точнее в collation.
В mysql вы использовали какой-то из вариантов case independent collation. например utf8_general_ci, который по умолчанию задается при выборе utf8.
Если вы будете использовать функцию lower, то, наверное, индекс не сработает.
Может вы ошиблись при настройке кодировки для базы?

FLUSH TABLES WITH READ LOCK;
Только эта конструкция глобально блокирует все операции записи в файлы на сервере. SELECT-ы работают.

Не очень понятны предпосылки к такому решению. Почему бы не воспользоваться репликацией или простым дампом?

Попробуйте поймать файл core, загрузить отладчик gdb и подцепить этот файл. Нужно сделать backtrace и попробовать понять на каком этапе работы происходит ошибка.
Вероятнее всего, будет видно в какой именно функции произошел сбой SIGSEGV. Отладочная информация не обязательно потребуется.

Я свою просто сфотографировал до того как она истерлась.

Не понятно, как можно запатентовать в 2000 году гораздо более древнюю концепцию ORM?

с некоторых пор, в ffmpeg есть отдельная программа ffprobe специально для этой цели.

В документации dlink про автоматический подхват RTP в h.323 ничего не написано.
Полный разбор h.323 подобные устройства не делают. Чтобы угадать динамический номер порта, используются эвристики — некоторые правила, описывающие по какому смещению в конкретном пакете находится порт который нужно пробросить дополнительно. Обычно.
На практике чуть более отличающиеся параметры эвристику ломают.
В вашем случае dlink, очевидно, не угадал.

И вообще, это ведь не бытовое устройство, а компонент корпоративной телефонии AVAYA.
Обратитесь уже к интегратору или где вы там его нашли. Он решит все проблемы за соответствующие деньги — продаст морщрутизатор организующий туннель между офисами.

Хороший повод открыть для себя транзакции в СУБД.

Тоже задавался этим вопросом.
Cгенерируйте немножко данных и проверьте использует ли индекс запрос с WHERE IS NULL ( думаю, 80% NULL будет нормально)
Если в плане показано использование индекса — значит в индексе хранятся ссылки на ВСЕ значения NULL, и, соответственно, разницы нет.
Было бы интересно создавать иногда компактные индексы по «разреженным» значениям, где ссылки на NULL-значения не хранятся, но обычно в этом случае делают связь один-к-одному с другой таблицей.

В foxit reader текст выглядит как текст и такие штуки как lingvo подхватывают текст под курсором. А вот с acrobat reader так не получается.

1.844E+19 в таблице типа myisam.
У innodb сложнее найти, но есть ограничение на 64Тб на файл, а значит и на таблицу.

Только эти знания вам никакой практической пользы не принесут.

Лучше расскажи в чем практический смысл этого?
Если речь о закрытии табов для побочных результатов при анализе многих сайтов, то лучше «tree style tab», как универсальное решение работы с большим числом логически связанных табов.

Я бы зарулил всю почту в imap-аккаунт и обучил бы «этого дядю с большими ушами» перекладывать письма в клиенте в две разных папки
Простейшая программа переодически выкачивает из папки письма и переправляет на отправку. Разумеется, чистит папку за собой, а папку с отвергнутыми просто чистит.
Немного странные заголовки Received получатся, но бывает и хуже. Их можно в той же программе почистить.

Вопрос неоднозначный. Лучше тестируйте и то и другое.

Вот вы знаете, что если достаточно крупными блоками и достаточно много параллельных скриптов будут писать в файл, то сообщения могут перемешаться?
тут возникает необходимость синхронизировать доступ к файлу, а значит возникает узкое место, где все параллельные процессы блокируются.
Тогда как в CУБД уже есть некоторые интересные и бесплатно доступные механизмы типа INSERT IGNORE, которые возвращают результат «мгновенно».
Prepared statements и пул соединений тоже будут не лишними.

Еще есть мнение, что по-настоящему нагруженному проекту логи действий пользователей вообще не нужны. Разве что во время отладки.