К счастью, можно особо не париться с типами и для всех переменных указывать тип "s".
Пробовал гуглить, как указывать тип, ничего не нашёл.
сразу бросаются хранение типов и статусов в строках, переделай в числа, должно заметно уменьшить базы данных, уменьшить объем базы и индексов.
лучше всего enum
Скорость выполнения одинаковая
WHERE (task.status, task.type, task.provider, task.cat) = ('active', 'follow_profile', 'insta', 3)
Серверу пофиг, но как бы нагляднее. к таблице приёмы, паровозиком идут еще несколько: файлы и свойства приёма
Использовать Partitioning для таблицы "приёмы", понятно по годам, а вот для связанных таблиц файлы и свойства приёма, что лучше делать?
подумал сделать Partitioning допустим по годам
есть несколько таблиц, которые занимают 95% места всей БД.
правильно ли я понимаю, что оба диапазона по 16 адресов можно покрыть одной общей маской 194.58.64.0/19 ?
Что-то мне понимание принципа объединения этих адресов трудно дается...
можно как-то колонке добавить свойство, что по умолчанию всегда там значения без пробелов?
Есть такое в InnoDB. Но связано с необходимостью существования выражения для кластерного индекса. И применяется только в случае отсутствия индекса-кандидата на эту роль, каковым может быть не только первичный, но и просто уникальный индекс, не использующий nullable поля.
Clustered and Secondary Indexes