Изначально неправильный подход к реализации, у которого будут глюки в проблемных местах. К тому же слишком сложный у вас получился вариант.
Если база данных в своей основе не позволяет нужны вам функционал, как бы вы не извращались, делать его придется снаружи. И лучше чтобы это было 'userspace' а не ядро базы данных или ее расширение, так как стоимость поддержки результата растет экспоненциально.
Правильный подход - у вас работает ваше приложение (не крон), которое в момент изменения/добавления временных интервалов будет вычислять какой следующий интервал в ближайшее время должен тригериться, ждать соответствующее время и исполнять его.
В базе данных (таблица задач), в зависимости от необходимости, у вас должны быть следующие поля:
* таймстамп создания интервала (нужен чтобы вычислять сколько раз должен исполниться и уже исполнился интервал)
Уже в этот момент появляется важное замечание, нужно понимать что время на машине может быть изменено, скорректировано назад например и в зависимости от того на сколько вам важно не пропустить или не получить лишнее исполнение, можно использовать синтетические значения, в т.ч. использовать специальные процессорные счетчики, значение которых не меняется при смене времени, конечно придется добавлять инструменты корректировки/инициализации при перезапуске службы, отдельный разговор и задача.
* временной интервал между повторениями
* лимит количества исполнений - здесь указывается максимальное количество раз исполнений задачи
* количество исполнений - счетчик должен увеличиваться при исполнении задачи
еще нужно учесть что есть просто попытки исполнения и есть успешно завершенные, бывают задачи, при которых не успешные попытки тоже должны быть учтены, так как контроль за ошибками системы важен.
Все изменения интервалов должны проходить через вашу службу или вы должны собирать нотификации базы данных о таких изменениях (некоторые базы данных дают такой инструментарий, позволяют передавать события через отдельные сокеты или даже сессию подключения клиента), правда вам придется учитывать что записи в базе транзакционные и если вдруг произойдет откат записи об интервале а вы уже обработали событие (или наоборот в базе транзакция прошла а у вас из-за ошибки событие не обработалось), поэтому проще управлять интервалами через свое приложение.
В момент когда приложение получает новую ситуацию по интервалам, оно вычисляет какой ближайший интервал и когда закончится, и запускает счетчик времени, который должен быть отменен при получении новых изменений.
По окончанию работы счетчика вы должны снова запросить из базы данных список задач которые опоздали или должны быть исполнены сейчас, вычисляя разницу между расчетным количеством исполнений (now - creation_time)/exec_interval и счетчиком исполнений (тут же проверяем лимит количества запусков, и при его превышении задачу удаляем, не забыв доделать нужное количество запусков). Для каждой задачи получаем количество исполнений - запускаем эти задачи и по окончанию каждой итерации увеличиваем счетчик исполнений.
p.s. разделение задач по разным таблицам в зависимости от длины интервала никак на производительность не повлияют, только усложнят алгоритм