Прежде всего: у вас есть проблемы с производительностью? Если нет, то зачем волноваться?
Тогда: Вам нужно хранить десятичные дроби, но иногда вас интересует только целая часть. Да?
Итак, у вас есть один или несколько запросов типа
where number >= 14 and number < 15
или
where truncate(number, 0) = 14
У вас уже есть индексы по номеру? Э.Г.
create index idx on mytable(number);
Первое упомянутое предложение WHERE
, вероятно, выиграет от этого. Второе - нет, потому что когда вы вызываете функцию для столбца, СУБД больше не видит связи с индексом. Это показывает, что вы можете изменить способ написания запроса.
Если первое предложение WHERE
все еще слишком медленное, несмотря на индекс, вы можете создать вычисляемый столбец (ALTER TABLE mytable ADD numint int GENERATED ALWAYS AS truncate(number, 0) STORED
), индексировать его и получить к нему доступ вместо столбца числа в вашем запросе. Но я сомневаюсь, что это заметно ускорит процесс.
Что касается вашего примера:
при наличии 10000 номеров, 5000 из которых начинаются с 14
Это не большой стол, а маленький. И поскольку вам все равно понадобится половина записей, СУБД будет просто читать все записи последовательно и смотреть на число. Не имеет значения, смотрит ли он на целое или десятичное число. (Ну, может быть, несколько наносекунд, но вы ничего не заметите.)