Дмитрий Аствафьев, С локальной машины если открыть 127.0.0.1 - открывается то что нужно? Также, если в адресную строку вставить IP адрес, который выдается Вам роутером - открывается то что нужно?
Анатолий, Я бы все таки не выделял "перевод" как сущность, а он был бы атрибутом у текущих сущностей. Так конечно количество таблиц увеличится, но все будет по полочкам. Т.е. `news` и `news_data`, `pages` и `pages_data`. При добавлении языка в этом варианте - нужно просто добавить новую запись в `langs` и склонировать во всех таблицах `*_data` данные с языка по умолчанию. Данную схему реализовывал когда то давно на "свой велосипед / своя CMS" и он был довольно рабочий. В свое время тоже задавался этим вопросом и рассматривал разные варианты. В итоге решил выбрать тот, что советую.
А зачем Вы дублируете news_id ? Это по факту суррогатный ключ, нуждны в котором нет. Собственно Ваше решение - это как раз то, о чем я описывал - что за сущность отвечает одна таблица, а за "языкозависимые данные" отвечает вторая. Если сделать запрос на подчиненную, то через нее по внешнему ключу можно выйти на главную. Единственное я бы в Вашем случае объединил id и news_id и первичный ключ на news_id + lang
ALTER TABLE `tb_visits` ADD INDEX `idx_status_idad` (`status`, `idad`);
При порядке важно понимать по какому критерию меньше "окно" запроса. Для этого можно посмотреть
SELECT `status`, count(*) FROM `tb_visits` GROUP BY `status`;
SELECT `idad`, count(*) FROM `tb_visits` GROUP BY `idad`;
Чем выше селективность (для выборки по ключу меньше значений) у запроса - тот индекс и надо ставить первым. Т.е. проще сначала выбрать 1000, а потом из этой 1000 выбрать 20, чем выбрать 50000, а потом из этих 50000 выбрать 20
WiNNeR_tig, как видно из скрина - у Вас используется только индекс по полю status, а далее каждая из 55170 строк сравнивается в "ручном" режиме. Попробуйте сделать составной индекс по полям (именно в этом порядке) `status`, `idad`. Что в этом случае покажет EXPLAIN ? Т.е. нужно добиться того, чтобы в key был нужный индекс и rows было минимальным. Также желательно, чтобы Extra вообще было пустым.
WiNNeR_tig, У Вас в раз идет чтение всех 750к записей? или EXPLAIN показывает, что запрос при обработке использует все 750к записей? Попробуйте переопределить запрос таким образом, чтобы "окно" обработки было более меньшим. Также в данном случае лучше не использовать SELECT *, а перечислить нужные поля, это даст небольшой прирост.
К примеру, у Вас там хранятся некие логи. У каждой записи лога можно выделить характеристику, например, тип записи лога ("new_message", "login", etc). И таблица `log` уже делится на `log_new_message`, `log_login`.
Либо если такой характеристики нет, то можно построить аналог DHT. У каждой записи лога есть, к примеру, пользователь, который сгенерировал эту запись. Посчитав хэш от его id и через XOR преобразования - можно выбрать одну из нескольких таблиц, в которую пойдет запись. Полностью это проблему не решит, а возможно, создаст перегрузку лишь одной таблицы, если пользователи (у которых хэш будет "ближе по DHT" к запрашиваемой таблицу) создают львиную долю запросов. Т.е. по факту я так понимаю вам нужно сделать некий "маршрутизатор" из запросов и каждый должен идти в соответсвующую таблицу. Чтобы не менять логику приложения сильно - то можно сделать view на эти несколько таблиц. Т.е. это уже более тонкая оптимизация.
Я бы все таки попробовал реализовать первый описанный метод, а DHT и прочее оставить на "десерт" и попробовать поиграть с ним в свободное время.
dkrylov, Параное в данном случае предела не может быть, поскольку даже то, что твой кошель хранится на бирже может не всех устраивать, а то, что только сам имеешь доступ к wallet.dat - уже как минимум небольшой плюс. А по поводу делать слабозащищенный продукт - то никто не мешает взять у провайдера белый IP и разместить приложение на любой нестандартный порт + у себя дома + сейф + сигнализация + собакен + видеонаблюдение + итд.
Т.е. ответ выше - задачу то решает, а как его будет использовать автор вопроса - уже его дело.
