Выдержит ли MySQL?

[alrond]

Выдержит ли MySQL?

Выдержит ли MySQL?
если БД будет около 500 МБ...
структура очень простая: одна таблица, полей 13, но...
но записей около 10 миллионов...или более

Так вот вопрос...а выдержит ли сама бд?
если конечно тачка хорошая, количество запросов в секунду маленькое, памяти от 512 и больше...
где-то я ситал, что оптимально до 100 мегов для MySQL...

 

[Demiurg]

При правильной настройке выдержит.
а у тебя каждое поле будет по 4 байта ?

 

[Falc]

alrond
>>структура очень простая: одна таблица, полей 13, но...
>>но записей около 10 миллионов...или более
Странная какая-то структура.

>>количество запросов в секунду маленькое

Если запросы прямые и их мало, то выдержит без проблем.

 

[alrond]

Структура простая: по полям (все unsigned)
1) varchar - самый главный элемент базы. нормально, длина будет от1 до 20 байт, редко, когда больше
2) tinyint
3) int
4) date
5) date
6) smallint
7) smallint
8) mediumint
9) tinyint
10) tinyint
11) int
12) int
13) tinyint
14) номер записи int

итого 35 байт + varchar (1...25) на запись (около 7 миллионов)

индексы должны быть по 9) и 5) обязательно...желательно еще и по 1), но я пока не представляю, насколько это может утяжелить систему, так как это главное поле, да к тому же половину базы данных бедет занимать

сложных запросов не будет
выборка по 14)
поиск по 5) + 9)
поиск по 1)

 

[Falc]

>>выборка по 14)
Вот по 14 должен быть индекс обязательно.

>>поиск по 1)
Если есть поиск индекс должен быть, возможно полнотекстовый.

 

[Demiurg]

Если хочешь, что бы быстрее работало, то тебе нужен не варчар а чар.

 

[Falc]

Demiurg
>>Если хочешь, что бы быстрее работало, то тебе нужен не варчар а чар.
Кстати не всегда

 

[Demiurg]

>Кстати не всегда
а в каких случаях это не поможет ?

 

[Falc]

Demiurg
На скорость индексных выборок это не влияет.
Так что если изменений в таблице мало, то нет смысла делать чар вместо варчар.

 

[Demiurg]

Falc
Ну я тут утверждать ничего не могу, но думаю, что это не помешает.

 

[Falc]

Итак провел экспиремент.

Таблица:
CREATE TABLE test (
id mediumint(8) unsigned NOT NULL auto_increment,
name varchar(24) binary NOT NULL default '',
PRIMARY KEY (id),
UNIQUE KEY name (name)
)

120 тыс. записей.

Выборки типа:
SELECT SQL_NO_CACHE *
FROM test
WHERE name LIKE 'xxx%'

Если резултатом выборки является около 20 записей, то время выборки для CHAR и VARCHAR совпадают.
Если резултатом выборки является около 200 записей. то время выборки для CHAR и VARCHAR отличаются на где-то на 20% в пользу CHAR.

 

[alrond]

Автор оригинала: Demiurg
Если хочешь, что бы быстрее работало, то тебе нужен не варчар а чар.

Так как чар-поля могут быть (в данном случае) ОЧЕНЬ разной длины, то я думаю лучше варчар. Обычные значения лежат в диапазоне 1-20 символов, но могут достигать и 40, и 50 ((

Кстати результатом выборки (по 1)будет всегда одна запись
простой поиск по базе и сравнение на наличие этого элемента
Пришел к выводу, что варчар лучше, так как размер базы существенно отличаться будет от заранее определенного чара, в меньшую сторону
Всем большое спасибо!

 

[Demiurg]

Странно, что ты смотришь только на размер базы, а не на результаты тестов Фалка. Хотя оптемизация размера тоже иногда имеет место. Вообщем тебе решать.

 

[alrond]

Да нет...просто я смотрю как на скорость, так и на размер.
И приходится выбирать между приростом скоростьи в 20%
и увеличением для этого базы раза в 3-4 ((

 

[confguru]

alrond

База 70Гб - несколько толстых таблиц..
Поиск от 3 до 5сек..
Вроде выдерживает..

 

[echo_nick]

Нехило.