anonymous@RULINUX.NET~# | Last login: 2024-12-23 12:45:25 |
Регистрация Вход | Новости | Разметка | Пользователи | Галерея | Форум | Статьи | Неподтвержденное | Трекер | Правила форума | F.A.Q. | Ссылки | Поиск |
Форум - Rulinux.net | [RSS] |
1) lastmod - уже сказал
2) индексы
судя по дампу вы вообще их не используете кроме primary key. сделайте как минимум:
ALTER TABLE forums ADD INDEX (forum_id); ALTER TABLE forums ADD INDEX (thread_id); ALTER TABLE forums ADD INDEX (sort);
ALTER TABLE forum_messages ADD INDEX (forum_id); ALTER TABLE forum_messages ADD INDEX (thread_id); ALTER TABLE forum_messages ADD INDEX (posting_date);
ALTER TABLE forum_threads ADD INDEX (forum_id); ALTER TABLE forum_threads ADD INDEX (stat); ALTER TABLE forum_threads ADD INDEX (posting_date);
3) тотально вынесите все запросы к базе в отдельные функции в отдельный файл
4) заведите раздел "о сайте" где выкладывайте актуальный срез движка с именем архива содержащим его версию пока нет git репозитария
5) точить, точить и точить :)
anonymous(*) (2009-05-13 23:28:53)
Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.10 (like Gecko) (Debian)
|
|
|
progman(*)(2009-05-13 23:50:52)
Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.10 (like Gecko) (Debian) |
progman(*)(2009-05-13 23:58:05)
Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.10 (like Gecko) (Debian) |
Скрыть
Re:разноеА насколько сильно поднимет производительность вот это? > ALTER TABLE forums ADD INDEX (sort); |
Скрыть
Re:разное>А насколько сильно поднимет производительность вот это? участвует в запросе значит оптимизатор может использовать индекс особенно когда данных будет много. хуже не будет в любом случае, потому как insert/update будет явно меньше чем select. это то что сразу бросилось в глаза пока я смотрел сырцы на предмет lastmod progman(*)(2009-05-14 00:02:52)
Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.10 (like Gecko) (Debian) |
Скрыть
Re:разное> 1) lastmod - уже сказал ready > 2) индексы Спасибо за напоминание, тоже сделал, заодно пару ошибок нашел в структуре > 3) тотально вынесите все запросы к базе в отдельные функции в отдельный файл Тут немножко другая структура работы с базой. все основные функции в classes > 4) заведите раздел "о сайте" где выкладывайте актуальный срез движка с именем архива содержащим его версию пока нет git репозитария Как свн подымим :-) |
Скрыть
Re:разноеПо смыслу там данных будет немного, а вот запросы, в которых это поле участвуют - будут, я думаю, full scan. Т.е. если этот индекс и будет использоваться по какой-то нелепой случайности, то это только добавит лишнее I/O к исполнению запроса. |
Скрыть
Re:разное>Т.е. если этот индекс и будет использоваться по какой-то нелепой случайности, то это только добавит лишнее I/O к исполнению запроса. с чего это вдруг ? просто индекс не будет использоватся. progman(*)(2009-05-14 00:11:26)
Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.10 (like Gecko) (Debian) |
Скрыть
Re:разное>Тут немножко другая структура работы с базой. все основные функции в classes что мешает вызывать эти функции из методов ? лучше весь SQL сгрупировать в одном файле это и поможет код причесать и на PostgreSQL потом спрыгнуть progman(*)(2009-05-14 00:13:30)
Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.10 (like Gecko) (Debian) |
Скрыть
Re:разноеИз этих двух первый мне тоже кажется избыточным: > ALTER TABLE forum_messages ADD INDEX (forum_id); ALTER TABLE forum_messages ADD INDEX (thread_id); |
Скрыть
Re:разноечаще быстрей и проще насоздавать индексов даже не особо вникая, а потом тупо посмотреть статистику их использования (в postgres по крайней мере) и тюнить уже более детально progman(*)(2009-05-14 00:17:33)
Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.10 (like Gecko) (Debian) |
Скрыть
Re:разное> ну вот возьми более полный дамп выпроси у создателей и EXPLAIN нам покажи там и увидем будет он использоваться или нет А смысл это делать, если и так понятно, что при использовании производительность только ухудшится, а при неиспользовании он всё равно не становится нужен. |
Скрыть
Re:разное> чаще быстрей и проще насоздавать индексов даже не особо вникая, а потом тупо посмотреть статистику их использования (в postgres по крайней мере) и тюнить уже более детально Ну в жёских условиях домашнего расслабона, когда никто никуда не спешит и сдавать к сроку ничего не надо - можно позволить себе и подумать, для общего развития организма так сказать.. |
Скрыть
Re:разное>если и так понятно, что при использовании производительность только ухудшится кому понятно ? объемы подрастут и совершенно не понятно будет. не говоря о том что это вообще mysql progman(*)(2009-05-14 00:25:19)
Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.10 (like Gecko) (Debian) |
Скрыть
Re:разное>Ну в жёских условиях домашнего расслабона, когда никто никуда не спешит и сдавать к сроку ничего не надо - можно позволить себе и подумать, для общего развития организма так сказать.. Рекомендуется подумать в любых условиях ибо иначе спешить придется еще больше. progman(*)(2009-05-14 00:27:15)
Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.10 (like Gecko) (Debian) |
Скрыть
Re:разное> кому понятно ? Даже ежу ИМХО. > объемы подрастут Сколько записей ты ожидаешь увидеть на этой странице когда подрастут объёмы: http://www.lor-ng.org/view-section.php ? > и совершенно не понятно будет. не говоря о том что это вообще mysql В каком юзкейсе это поле появляется в условии выборки? |
Скрыть
Re:разное>Даже ежу ИМХО. Чем больше будет кода тем тяжелей будет держать все в голове, далее запросы могут видоизменяться и тд. Сейчас запросы в любом случае не оптимальны и вероятно будут меняться, объединятся, анализироваться explain, анализироваться статистистика использования индекса. В данном случая я глядел на код секунд 30 на предмет внедрения туда lastmod - что увидил с ходу сказал - хуже не будет в любом случае. progman(*)(2009-05-14 00:35:07)
Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.10 (like Gecko) (Debian) |
Скрыть
Re:разное> Чем больше будет кода тем тяжелей будет держать все в голове, далее запросы могут видоизменяться и тд. Вот по этому и нужно избегать создания лишних сущностей, что бы кто-то другой (или сам автор через некоторое время), кто будет сидеть и разбираться с ситемой, не ломал бы голову - зачем же там создан этот бесполезный индекс.
|
Скрыть
Re:разное>Вот по этому и нужно избегать создания лишних сущностей Лишние сущности будут в любом случае если это не hello world >что бы кто-то другой (или сам автор через некоторое время), кто будет сидеть и разбираться с ситемой, не ломал бы голову Для этого есть DBA >зачем же там создан этот бесполезный индекс. для этого есть статистика использования индекса temy4 это помогло и это главное в изначальном посыле. the end. progman(*)(2009-05-14 00:46:56)
Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.10 (like Gecko) (Debian) |
Скрыть
Re:разное> Лишние сущности будут в любом случае если это не hello world Вот поэтому нужно стараться избегать хотя бы заведомо лишних сущностей. > Для этого есть DBA DBA не разрабатывают продукт. >> зачем же там создан этот бесполезный индекс. > для этого есть статистика использования индекса Никакая статистика не ответит на вопрос ЗАЧЕМ ты создал такой индекс. > temy4 это помогло и это главное в изначальном посыле. the end. Не понял этой фразы. |
Скрыть
Re:разное>DBA не разрабатывают продукт. А чем же он занимается как не анализом и оптимизацией запросов и индексов ? >Никакая статистика не ответит на вопрос ЗАЧЕМ ты создал такой индекс. Еще раз - на решение о предложении использовать вышеперечисленые индексы ушло 30 секунд - много меньше чем я спорю ни о чем тут. Хуже не будет. Лучше может. Конкретно этот индекс может и будет бесполезен для текущих запросов, а для будущих может будет полезен - это будет видно в статистике его использования. >Не понял этой фразы. фраза о том что предложения помогли ("Спасибо за напоминание, тоже сделал, заодно пару ошибок нашел в структуре") и это главное. А о чем мы тут спорим не понимаю. Сказать то чего хотите ? progman(*)(2009-05-14 01:00:58)
Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.10 (like Gecko) (Debian) |
Скрыть
Re:разное> А чем же он занимается как не анализом и оптимизацией запросов и индексов ? Организацией беспереперебойной работы самой СУБД, вопросами резервного копирования, ну вот консультациями всяким долбоёбам, увешивающим индексами таблицы как новоднюю ёлку шариками :) Ну вот сам посуди - разработчики где-то сделали какой-то продукт. Потом этот продукт где-то поставили и пытаются использовать. Периодически у ДБА внедренцев возникают вопросы по поводу тех или иных индексов, которые поступают в службу техподдержки - а зачем этот индекс, нельзя ли его убрать? Техподдержка переадресует такие запросы в сервис на стороне производителя продукта, тамошняя техподдержка переадресует вопрос девелоперам, те отвечают: "а, нам, блянах, некогда думать было". Сервисная служба производитетеля ПО отправляет сообщение саппорту заказчика: "нашим разрабам блянах думать некогда, они лепят чо попало". Служба поддержки на стороне заказчика перенаправляет этот ответ ДБА, который, прочитав подобный ответ, в очередной раз крутит пальцем у виска и пишет служебку менеджеру отдела по планированию крокодилов с рекомендацией запланировать перевод бизнеса на использование альтенативного пакета программ от более адекватного поставщика, который может ещё и откатом поделиться обещал, если ДБА пробьёт его продукт. > Еще раз - на решение о предложении использовать вышеперечисленые индексы ушло 30 секунд - много меньше чем я спорю ни о чем тут. Хуже не будет. Лучше может. Конкретно этот индекс может и будет бесполезен для текущих запросов, а для будущих может будет полезен - это будет видно в статистике его использования. Не надо решать несуществующие проблемы, к тому же плодя лишние сущности при этом. > фраза о том что предложения помогли ("Спасибо за напоминание, тоже сделал, заодно пару ошибок нашел в структуре") и это главное. А о чем мы тут спорим не понимаю. Сказать то чего хотите ? Я хочу сказать, что лишние индексы создавать не нужно. Вроде бы даже и сказал это неоднократно. |
Скрыть
Re:разное>консультациями всяким долбоёбам, увешивающим индексами таблицы херовый какой-то DBA что права на создание индексов дал - сам создавать должен. >Не надо решать несуществующие проблемы, к тому же плодя лишние сущности при этом. Это мягкое предложение заткнуться и больше со своими советами не лезть ? Я подумаю. Автору сайта начальный пост уже помог и это для меня имеет гораздо больший вес чем ваши пространные предложения. >Я хочу сказать, что лишние индексы создавать не нужно. Я хочу сказать что хуже от них не будет, а лучше может быть. Что запросы могут еще не раз видоизмениться. Что они наверняка изменяться так как не оптимальны. Что это начальный этап разработки. Что о том что будет нужно в конце пока не знают даже авторы, а уж тем более я который смотрел на это 30 секунд. Что существует статистика использования индексов. Что наверняка нужны будут многоколоночные индексы и более глубокий тюнинг с EXPLAIN, а пока даже оказавшийся лишним индекс не помешает. progman(*)(2009-05-14 01:42:31)
Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.10 (like Gecko) (Debian) |
Скрыть
Re:разное> херовый какой-то DBA что права на создание индексов дал - сам создавать должен. Ну да, ему больше заняться нечем.. ДБА этот продукт не делал, ему сказано - вот это должно быть установлено, требования производителя такие-то. И всё. Объекты базы вместе с индексами - это часть продукта. Пока проблема не возникнет - ДБА и не будет разбираться в каких обстоятельствах может потребоваться тот или иной индекс. Когда проблема возникнет - он не будет трогать индекс самостоятельно, поскольку предполагается, что он там по какому-то делу вкрячен разработчиком - кто его знает этот индекс, вдруг ДБА не учёл что где-то функциональность нуждается в этом индексе и какие-то бизнес-функции просто встанут без него, а убытки повесят на ДБА за его инициативу? Не, адекватный ДБА напишет бумажку, что вот этот индекс создаёт нагрузку на систему, которая так-то и так-то вредит повседневным функциям, выполняемым базой данных, типа прошу разобраться - зачем ему брать на себя лишнюю ответственность, у него своей хватает. > Это мягкое предложение заткнуться и больше со своими советами не лезть ? Я подумаю. Автору сайта начальный пост уже помог и это для меня имеет гораздо больший вес чем ваши пространные предложения. Да не, скорее наоборот - лезть с советами, решающими существующие проблемы :) > Я хочу сказать что хуже от них не будет, а лучше может быть. Что запросы могут еще не раз видоизмениться. Что они наверняка изменяться так как не оптимальны. Что это начальный этап разработки. Что о том что будет нужно в конце пока не знают даже авторы, а уж тем более я который смотрел на это 30 секунд. Что существует статистика использования индексов. Что наверняка нужны будут многоколоночные индексы и более глубокий тюнинг с EXPLAIN, а пока даже оказавшийся лишним индекс не помешает. Ну что я могу на это ответить? Только одно - не надо создавать лишние сущности хотя бы потому, что когда всё изменится, разбираться с продуктом, содержащим завалы лишних вещей будет сложнее, чем с продуктом их не содержащим.
|
progman(*)(2009-05-14 02:13:36)
Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.10 (like Gecko) (Debian) |
Скрыть
Как купить топик?Хотел бы разместить рекламу на www.lor-ng.org, в разделе этот т.е. его надо закрепить. Подскажите, возможно ли это и сколько это будет стоить? Для начала на месяц. |
Скрыть
Позвольте узнать раскажитеКто знает какие нибудь магазины лидирующии, в городке Шостка, за внимание буду признателен, там буду в первые, не орентируюсь в целом. |
Скрыть
Знаю, этот городок.самоочевидно острая статья Шостка. м-н стройматериалов Стоим Мы http://in4rm.org/articles/shostka_m_n_stroimaterialov_stoim_my anonymous(*)(2009-07-23 15:02:22)
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322; Alexa Toolbar; (R1 1.5)) |
Скрыть
Кто бы мог подумать!Три дня назад наведоволся туда персонал на спецобслуживание Я был поражен! Глуховский автовокзал http://shostkainfo.com.ua/hlukhiv_avtovokzal/ anonymous(*)(2009-07-23 15:13:04)
Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; .NET CLR 1.1.4322) |
Скрыть
В общих чертах обрисовать можно, всё найдёш.ТОВ "Шостка-Райкомунгосп" http://in4rm.org/articles/tov_shostka_raikomungosp anonymous(*)(2009-07-23 15:23:33)
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; APC; .NET CLR 1.0.3705; .NET CLR 1.1.4322; .NET CLR 2.0.50215; InfoPath.1) |
Скрыть
Корпорация платит за просмотр видео и участие в опросах. 3.60 wmz за часЗароботок на дому., Cтартует проект - intVideo, ссылка: http://intvideo.tv Это принесет дополнительный доход. Корпорация платит за просмотр видео и участие в опросах. 3.60 wmz за час За что платят?Прежде всего, за просмотр рекламных роликов и участие в видео-опросах. Вы будете получать $3.60 за 1 час просмотра. Второй, не менее важный источник доходов - рефералы. Если вы пригласите 100 человек, то будете получать до 300-500 долларов в месяц. Это и есть пассивный доход, о котором вы так много слышали. При регистрации нужно ввести Этот код 000014q4l40m |
Скрыть
Презентую на всемирное освидетельствованиеПреподношу на всеобщее рассмотрение Шосткинскую суперорганизацию, Шостка м-н «АвтоДом» http://in4rm.org/articles/shostka_m_n_avtodom на сцене довольно давнешенько, показала себя с одобрительной стороны, интригуют все Ваши ответы, всем на свете покорно благодарю. |
|
|
|
Этот тред читают 3 пользователя: |
Анонимных: 3 Зарегистрированных: 0 |
Re:разное
> сделайте как минимум:
Ну как минимум вот это явно лишнее:
> ALTER TABLE forums ADD INDEX (forum_id);