- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Что делать, если ваша email-рассылка попала в спам
10 распространенных причин и решений
Екатерина Ткаченко
В 2023 году Google заблокировал более 170 млн фальшивых отзывов на Картах
Это на 45% больше, чем в 2022 году
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Есть таблица, с графиками, с 10 полями. В ней есть одно свойство, оно либо включено либо выключено. Если это свойство включено (prop=1)то у графика есть определенные классификации, около 10 (prop1 ...prop10). Таблица графиков велика, свойство включено где то у 1% графиков, вопрос в следующем.
prop и propN только 0 или 1 (int(1) планирую)
сама по себе таблица графиков (gr_table ) очень часто select использует и реже update
Как лучше поступить если надо на определенной странице выводить эти графики.
а. создать дополнительную таблицу связанную с айди графика + свойства
new_table { gr_id, prop1, ....
б. просто добавить свойства в исходную таблицу
gr_table {gr_id, otherfields...., prop, prop1 ....
должна быть поиск по свойствам WHERE prop1=1
проще и целостней второй вариант, но не знаю как он скажтся на быстродейсвии большой таблицы, а , правильней кажется первый.
спасибо.
Miracle добавил 29.12.2010 в 07:16
prop1 ... значени только true и false
может можно сделать поле int(3) и работать с битовыми данными? но не знаю проще и быстрее ли это. да возможно экономия места в таблице будет и по индексам так же
Таблица графиков велика
"Велика" — это какого размера? А то у всех разные представления о великости :)
И вообще, напишите лучше конкретные примеры, а то я лично смутно понимаю, какие у вас таблицы и что вы от них хотите )
Соглашусь, нужно больше данных о структуре и примеры запросов. И с ходу - что именно сообщает EXPLAIN на каждый вариант запросов.
prop и propN только 0 или 1 (int(1) планирую)
. . .
должна быть поиск по свойствам WHERE prop1=1
Выборка по условиям с целочисленными полями типа int(1) врядли будет тормозить, имхо надо делать как удобнее.
я смотрю в будущее, и могу сказать что кол-во графиков увеличивается
сейчас , не много 120000 тыс., но я же о будущем думаю :)
]И вообще, напишите лучше конкретные примеры, а то я лично смутно понимаю, какие у вас таблицы и что вы от них хотите )
а что конкретней написать.
вроде написал
текущая аблица с полями
gr_table {gr_id, otherfields...., prop), prop1 ....
первый вариант дополнительная таблица new_table { gr_id, prop1, ....
второй вариант с доп полями gr_table {gr_id, otherfields...., prop, prop1 ....
не знаю, мне кажется оригинал таблицы вас только сбивал., я же все упростил
я смотрю в будущее, и могу сказать что кол-во графиков увеличивается
сейчас , не много 120000 тыс., но я же о будущем думаю :)
а что конкретней написать.
Конкретней, прямо как оно выглядит
CREATE TABLE ... и т.д.
Вообще, даже если вы к таблице с 1 млн строк добавите ещё 10 колонок INT, ничего страшного не случится.
По тем колонкам, по которым поиск не осуществляется, можно сериализировать и запихнуть в одну колонку varchar
вот таблица
`gr_id` int(11) unsigned NOT NULL auto_increment,
`user_id` int(11) unsigned NOT NULL default '0',
`gr_1day` date default NULL,
`gr_a_days` tinyint(3) unsigned default '31',
`gr_b_days` tinyint(3) unsigned default '3',
`gr_text` text,
`gr_last_use` int(11) default NULL,
`gr_activity` tinyint(1) default '1',
`gr_x_day` tinyint(3) unsigned default NULL,
`gr_points_qty` smallint(6) default '0',
`gr_field_value_qty` smallint(6) default '0',
`gr_prop` tinyint(1) default '0',
`gr_prop1` tinyint(1) default '0',
`gr_prop2` tinyint(1) default '0',
`gr_prop3` tinyint(1) default '0',
`gr_prop4` tinyint(1) default '0',
`gr_prop5` tinyint(1) default '0',
`gr_prop6` tinyint(1) default '0',
`gr_prop7` tinyint(1) default '0',
PRIMARY KEY (`gr_id`),
KEY `bt_FKIndex1` (`user_id`),
KEY `user_id` (`user_id`),
KEY `gr_activity` (`gr_activity`),
KEY `gr_prop` (`gr_prop`),
KEY `gr_prop1` (`gr_prop1`),
KEY `gr_prop2` (`gr_prop2`),
KEY `gr_prop3` (`gr_prop3`),
KEY `gr_prop4` (`gr_prop4`),
KEY `gr_prop5` (`gr_prop5`),
KEY `gr_prop6` (`gr_prop6`),
KEY `gr_prop7` (`gr_prop7`)
)
вот таблица
ну вроде всё красивенько
prop и propN только 0 или 1 (int(1) планирую)
Таблица графиков велика, свойство включено где то у 1% графиков,
...
KEY `gr_prop` (`gr_prop`),
KEY `gr_prop1` (`gr_prop1`),
KEY `gr_prop2` (`gr_prop2`),
KEY `gr_prop3` (`gr_prop3`),
KEY `gr_prop4` (`gr_prop4`),
KEY `gr_prop5` (`gr_prop5`),
KEY `gr_prop6` (`gr_prop6`),
KEY `gr_prop7` (`gr_prop7`)
это плохой выбор индексов с точки зрения экономии места и скорости обновлений таблицы. В индексах хранится каждое значение 0 или 1 для каждой записи.
так что удалить эти индексы и проверить будет ли достаточно индексов bt_FKIndex1, user_id. Мне почему-то кажется, что будет.
Если true в данных полях очень разрежено, то можно каждое булевое поле заменить отдельной таблицей отношений. В этом случае все будет довольно компактно хранится, потому что для 0 используется факт отсутствия записи-отношения.
И где сами данные графиков хранятся? уж не ерундой ли вы себе голову забиваете?
это плохой выбор индексов с точки зрения экономии места
да. таблица увеличилась почти в двое
и скорости обновлений таблицы
потому собственно и спрашивал
В индексах хранится каждое значение 0 или 1 для каждой записи.
это логично, но не понятно к чему вы это сказали, есть альтернатива?
так что удалить эти индексы и проверить будет ли достаточно индексов bt_FKIndex1, user_id. Мне почему-то кажется, что будет.
пожалуйста, уточните что надо сделать, я ничего не понял.
Если true в данных полях очень разрежено, то можно каждое булевое поле заменить отдельной таблицей отношений. В этом случае все будет довольно компактно хранится, потому что для 0 используется факт отсутствия записи-отношения.
в самом начале об этом и спрашивал.
И где сами данные графиков хранятся? уж не ерундой ли вы себе голову забиваете?
простите. дальше не понял, хранятся в mysql
да. таблица увеличилась почти в двое
это логично, но не понятно к чему вы это сказали, есть альтернатива?
пожалуйста, уточните что надо сделать, я ничего не понял.
в самом начале об этом и спрашивал.
Альтернатива - не создавать индексы и надеяться что без индексов выборка тоже будет достаточно хороша.
Другая альтернатива - создавать дополнительные ссылающиеся таблицы.
Сообщение от netwind
так что удалить эти индексы и проверить будет ли достаточно индексов bt_FKIndex1, user_id. Мне почему-то кажется, что будет.
пожалуйста, уточните что надо сделать, я ничего не понял.
просто удалить все индексы на поля tinyint и не париться.
Я давно заметил, что вы всегда выдумываете разные вопросы про mysql не имея реальной проблемы. Это непрактично. Порекомендую вам просто генерировать достаточно большие и характерные тестовые данные, а потом уже искать узкие места и плохие запросы.