@andreyvlru: если у вас сохранится тенденция роста - вы все равно придете к разбиению контента по нодам и 99% что вы будете это делать логикой приложения.
@Cyapa: у меня нет перконы под рукой, предлагаю вам проверить это самостоятельно :)
Подумал что эксперименты на офисной машине не корректны, перенес на дев сервер hetzner px60, 5.5.37-MariaDB, innodb, кеши sql отключены.
SELECT * FROM `phones` WHERE `title` LIKE '790309%996' - 0.0050 sec
SELECT * FROM `phones` WHERE `title` REGEXP '7903099[1-3][0-9]9[1-9]' - 0.1791 sec
SELECT * FROM `phones` WHERE `title` = '79030991193' - 0.0002 sec
@Cyapa: вот не поленился, сделал. Тестовая табличка id (int 11), title (varchar 11)
1 000 000 записей. Не стал заморачиваться, все в utf. Таблица myisam. Размер таблицы 42.9Mb.
Построение полнотекстового индекса 6 секунд
SELECT * FROM `phones` WHERE `title` LIKE '790309%996'
0.20 sec
SELECT * FROM `phones` WHERE `title` REGEXP '7903099[1-3][0-9]9[1-9]'
@Cyapa: зачем вам хранить цифры в юникоде? :) Не понял откуда взялось 32 байта, при длине номера в 11 символов.
быстродействие сильно зависит от ваших запросов. Если искать regexp - будет ад.
Простые like % - скорее всего более менее приемлимо, но лучше протестировать самостоятельно.
@legolas4444: это не нормальная практика, но ресурсоемкие задачи оптимально решать как то так.
В качестве альтернативы можно хранить эти кеши например в redis и получив массив из N постов делать multiget в Redis. Тут очень зависит от реального кейса использования - насколько они востребованы, etc.
@shoomyst: у меня есть субъективное мнение что эти чудесные истории как раз предназначены для бездумной поддержки [старого] говнокода либо решения каких то ну очень специфических историй.
@wanomgn: UNSIGNED INT это 4 294 967 295. 4 миллиарда.
При миллиарде записей и идеальном распределении - вероятность коллизии (вообще) 25%.
Даже если будет коллизия из 10 значений - выбрать их по primary key и отфильтровать - не долго.
