фулскан по 23 тыщам это ЕРУНДА, милисекунды

Правда ваша.
Но я лично не сторонник такого подхода - напереписывался уже систем за разработчиками у которых если запрос визуально быстро выполняется - то и ладно. (Визуально это когда он enter в mysql CLI нажал и ответ довольно шустро выскочил). И такое запускается в продакшен. А потом число записей в базе увеличивается в 10-100 раз и система ложится.

Миллисекунды миллисекундам рознь - визуально вы ни 1, ни 10 ни 100 не отличите. А производительность системы меняется в разы. Но тут мы опять возвращаемся к главному вопросу - зачем это нужно. Если это делается в начале каждого звонка на системе которая обрабатывает 10 звонков в минуту - то в общем пофиг как делать. Если же это какой-то batch processor для огромного объема информации, то ускорение query в 10 раз - это по сути ускореение всей обработки в 10 раз.

И кстати, если считать что full scan это ок, то по-моему геморроится с дополнительным полем длины вообще не нужно - регексп сделает все горазддо элегантнее

SELECT *
FROM destinations
WHERE number_you_have REGEXP '^' + prefix
ORDER BY LENGTH(prefix) DESC
LIMIT 1

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

ну да, так и надо по хорошему - префиксное дерево построить в памяти и производительность при поиске будет такая что mysql'ю не снилось вообще - миллионы матчей в секунду....
но готов поспорить что мало кто так заморачиваться будет :)

написал статью в блог:
Trixbox: подстановка направления в CDR
выложил базу данных def кодов от MTT и методы ее использования.

полезный материал получился.

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

К примеру Укртелеком принимает номер только в E.164. Такие же требования предъявляют мелкие операторы.
Никто пищать DTMF'ом не будет -- это дело клиента.

DTMF'ом пищать не будет но длинный номер съест отбросив лишнее.