MySQL + 30 млн. записей - структура

[kvn]

MySQL + 30 млн. записей - структура

Привет всем!

Есть ~30 млн. строк, формата типа:

field1      field2    field3  field4
7829182783 9872189020 text1 1
7829182784 9872189025 text1 0

field1 - уникальные числа.
пары field1 и field2 - уникальны.

критерий - нужно спроектировать БД, чтобы максимально быстро выбирать пару field1 & field2.
Причем максимально (макс. критерий ~ 0.5 сек)

примеры частых запросов:

select * FROM tbl WHERE field1=7829182783 AND field2=9872189020;
UPDATE tbl SET field4=1 WHERE field1=7829182783 AND field2=9872189020;

инсертов или не будет вообще, или будет раз в неделю.

думаю, что mysql должна справиться с такой задачей,
но смущает количество записей + верхний критерий по времени,
хотел бы услышать советы гуру по поводу структуры.
Как правильнее?

Спасибо.

 

[Demiurg]

Поставь составной индех, если инсертов не будет и все.

 

[Falc]

kvn
>>field1 - уникальные числа.

Индекса по field1 хватит для приведенных запросов.

>>Причем максимально (макс. критерий ~ 0.5 сек)

тут многое зависит от нагрузки на сервер, у мнея бывало, что при сильной загрузке сервера выборки по первичному ключу ( при отсутствие нагрузки работают по 0.0003с. ) работали по несколько секунд.

 

[kvn]

Автор оригинала: Demiurg
Поставь составной индех, если инсертов не будет и все.

т.е. что-то наподобии

CREATE TABLE tbl (
id int(10) unsigned NOT NULL auto_increment,
field1 int(10) not null, 
field2 int(10) not null,
field3 varchar(100) not null,
field2 tinyint(1) not null,
PRIMARY KEY  (id),
KEY bb1 (field1),
KEY (field1, field2)
)
подправил немного....

типа так?

 

[Falc]

kvn
Интересно зачем тебе столько уникальных полей в одной таблице?

 

[kvn]

Интересно зачем тебе столько уникальных полей в одной таблице?

в смысле?
должно быть в двух таблицах?
или с этим какая то проблема?

 

[Falc]

kvn
>>в смысле?
Если у тебя field1 уникально, то можно обойтись без id. При таком кол-ве записей я думаю это будет актуально.

 

[kvn]

Если у тебя field1 уникально, то можно обойтись без id. При таком кол-ве записей я думаю это будет актуально.

согласен.
спасибо.
Еще какие-то иысли есть?

 

[Falc]

kvn
Свои мысли я написал выше еще в первом посте.

 

[kvn]

Учитывая пока что сказанное в треде, получаем такого вида структуру:

CREATE TABLE tbl (
field1 int(10) not null, 
field2 int(10) not null,
field3 varchar(100) not null,
field2 tinyint(1) not null,
PRIMARY KEY  (field1),
)

еще у кого-то будут мысли?
спасибо.

 

[Falc]

kvn
Кстати откуда у тебя берется field1 и используется он где-нибудь еще, если да то где?

 

[kvn]

м...
юзер топчет field1 и field2:
нужно посмотреть, есть ли в базе пара:
select count(*) from tbl where field1=$field1 and field2=$field2 and field4=0;

потом, сделать операции с др. таблицами (занести туда параметры юзера, field1, field2, etc..)
и сделать
update tbl set field4=1 where field1=$field1 and field2=$field2;

примерно так.

 

[Falc]

kvn
Ну тогда мыслей больше нету.

Правда varchar на таблице в 30 млн. строк не очень хорошо.

 

[si]

Правда varchar на таблице в 30 млн. строк не очень

правильно, лучше проиграть в потребляемом пространстве но иметь записи с фиксированной длинной.

 

[SiMM]

Если field1 и field2 уникальны - то не быстрее ли будет сделать запрос select * from tbl where field1=$field1 (или же field2=$field2), а уж затем средствами PHP выполнить проверку полей field2 и field4? Да и для update (раз уж field1 и field2 уникальы), думаю, достаточно использовать только одно из полей.
PS: kvn, а field2 int(10) not null, ... field2 tinyint(1) not null, - случаем, не очепятка?

 

[fixxxer]

Я так понимаю, что уникальна именно комбинация field1 и field2.
Иначе не вижу смысла в остальных условиях поиска.

 

[Falc]

SiMM
Не быстрее.

-~{}~ 04.03.04 10:25:

fixxxer
Почему ты не видешь смысла?
Сначало идет проверка по уникальному полю field1.
Если такое есть, то проверяется совпадают ли остальные поля.

Вот подобный пример:
SELECT *
FROM user
WHERE login = '$login' AND pass = '$pass'

Поле логин у нас уникальное, но мы заодно проверяем еще и пароль, чтобы не вытаскиватьпроверку в ПЫХ.