Как определить таблицу ключей/значений с 10 миллиардами строк в mysql?

Question

k | v 

k уникальная строка (VARCHAR 32), v также строка (VARCHAR 50),

Я буду делать только эти запросы:

insert into 
select v from TABLE where k = "${k}" 

Как я должен написать мой создать таблицу SQL Server?

как раздел в mysql? следует ли использовать его?

Например, следует ли использовать myisam или innodb?

У меня много прочитанных и немного вставных, поэтому может быть установлен замок InnoDB на уровне строк?

Answer 1

Это вопрос проверки? Предположим, что мы не позволяют NULL значения, и мы не позволяем дубликатами, я выбрал бы для индекса организованной таблицы:

CREATE TABLE mytable 
(k VARCHAR(32) NOT NULL COMMENT 'pk (cluster key), ...' 
, v VARCHAR(50) NOT NULL COMMENT 'pk (cluster key), ...' 
, PRIMARY KEY (k,v) 
) ENGINE=InnoDB 

Наиболее важным является ключом кластера, имеющего «к» быть ведущей колонки, из-за предиката равенства в предложении WHERE.

Если 'k' гарантированно будет уникальным, то он сам по себе может служить ПЕРВЫМ КЛЮЧОМ.

CREATE TABLE mytable 
(k VARCHAR(32) NOT NULL COMMENT 'pk (cluster key), ...' 
, v VARCHAR(50) NOT NULL COMMENT '...' 
, PRIMARY KEY (k) 
) ENGINE=InnoDB 

Это предотвратит создание INSERT строки, имеющей дублирующее значение «k».

В худшем случае, если предположения об ошибках и уникальности недействительны, то мы находимся в мире ранений с точки зрения предоставления кластерного ключа. Мы можем позволить InnoDB использовать внутренний идентификатор в качестве ключа кластера, а просто создать индекс покрытия для нашего запроса, что требует примерно в два раза больше места, из-за накладные расходы на внутреннем идентификатор, и отдельный индекс:

CREATE TABLE mytable 
(k VARCHAR(32) COMMENT '' 
, v VARCHAR(50) COMMENT '' 
, KEY mytable_IX1 (k,v) 
) ENGINE=InnoDB 

Это не так эффективно, но это позволяет дублировать и NULL. Опять же, нам нужен индекс с ведущим столбцом k (из-за предиката равенства в предложении WHERE), а также включая v (что делает его индексом покрытия), поэтому запрос SELECT может быть удовлетворен с индексных страниц, без необходимости поисковые страницы в базовой таблице данных.

MySQL поддерживает системы хранения, отличные от InnoDB. Это наше лучшее предположение, отсутствие каких-либо других спецификаций относительно кластеризации, репликации и т. Д.

Предполагая, что включено innodb_file_per_table, я бы рассмотрел разделение. Это не собирается перемещать иглу с точки зрения производительности запросов, но это может улучшить управляемость таблицы, например, если мы хотим, или нужно реорганизовать

PARTITION BY RANGE (k) 
    (PARTITION ke VALUES LESS THAN ('e') 
    , PARTITION ki VALUES LESS THAN ('i') 
    , PARTITION ko VALUES LESS THAN ('o') 
    , PARTITION ku VALUES LESS THAN ('u') 
    , PARTITION kz VALUES LESS THAN ('z') 
    , PARTITION px VALUES LESS MAXVALUE 
) 

Тогда мы могли бы реорганизовать раздел в то время, :

ALTER TABLE mytable REBUILD PARTITION ko;