Как вариант, можно разрешить редактировать свои комментарии в течение ограниченного времени. Написал комментарий — 10 минут на редактирование. Для того чтобы исправить ошибки, наверное, достаточно.
Простой способ немного ускорить выполнение запросов с большими лимитами:
Сначала найдем общее количество результатов:
SELECT COUNT(*) FROM item WHERE [тут какие-то наши условия]
Допустим, получилось 1015.
Теперь, вместо:
SELECT item_id FROM item WHERE… ORDER BY item_id LIMIT 1000, 15
можно написать:
SELECT item_id FROM item WHERE… ORDER BY item_id DESC LIMIT 0, 15
И потом уже выбрать данные:
SELECT… FROM item WHERE item_id IN ([массив из предыдущего запроса])
Запросы из первой половины будут обычные:
SELECT item_id FROM item WHERE… ORDER BY item_id LIMIT 200, 15
Самые медленные запросы получатся посередине, зато чем ближе к концу — тем быстрее.
Весьма удобно «хранить» пароли, например, так. Подобных сервисов много, да можно и свой сделать себе :)
Надо помнить один мастер-пароль, из которого и создаются пароли непосредственно для сайтов. Т.е. фактически пароли нигде не хранятся.
При использовании memcache надо обращать внимание на время коннекта. Оно может быть на порядок больше времени самой выборки и, таким образом, свести все преимущество на нет.
Что касается Memory tables в MySQL, советую помнить об ограничении на максимальный размер такой таблицы. Он определяется минимальным из параметров tmp_table_size и max_heap_table_size. Если размер вырастет больше - сервер просто откажется добавлять новые строки.
Хм... по-моему как раз FreeBSD не готова для рабочего сервера. 4-ка была не готова категорически, с 6-кой в этом плане лучше. Хотя конечно применения бывают разные.
А вот у linux сейчас с этим все хорошо - серверный дистрибутив готов к работе сразу после установки, не надо ничего подкручивать или пересобирать.
По производительности FreeBSD к сожалению тоже не впереди - файловая система медленная, SMP так себе. Посмотрим что будет в 7-ке.
Хотя мне тоже кажется что просто разные данные.
Сначала найдем общее количество результатов:
SELECT COUNT(*) FROM item WHERE [тут какие-то наши условия]
Допустим, получилось 1015.
Теперь, вместо:
SELECT item_id FROM item WHERE… ORDER BY item_id LIMIT 1000, 15
можно написать:
SELECT item_id FROM item WHERE… ORDER BY item_id DESC LIMIT 0, 15
И потом уже выбрать данные:
SELECT… FROM item WHERE item_id IN ([массив из предыдущего запроса])
Запросы из первой половины будут обычные:
SELECT item_id FROM item WHERE… ORDER BY item_id LIMIT 200, 15
Самые медленные запросы получатся посередине, зато чем ближе к концу — тем быстрее.
Надо помнить один мастер-пароль, из которого и создаются пароли непосредственно для сайтов. Т.е. фактически пароли нигде не хранятся.
Насчет второго - да, проблемы нет. Просто особенность.
Что касается Memory tables в MySQL, советую помнить об ограничении на максимальный размер такой таблицы. Он определяется минимальным из параметров tmp_table_size и max_heap_table_size. Если размер вырастет больше - сервер просто откажется добавлять новые строки.
А вот у linux сейчас с этим все хорошо - серверный дистрибутив готов к работе сразу после установки, не надо ничего подкручивать или пересобирать.
По производительности FreeBSD к сожалению тоже не впереди - файловая система медленная, SMP так себе. Посмотрим что будет в 7-ке.
(не знаю к какой версии относится)