Какие могут быть проблемы при сортировки с параметризуемым методом?

Какие могут быть проблемы при сортировке с параметризуемым методом?

Это очень важный практический вопрос, касающийся безопасности и производительности API. При передаче параметров сортировки из клиента в backend возникает множество проблем.

1. SQL Injection через параметры сортировки

Самая опасная проблема — SQL injection при динамическом построении ORDER BY:

// ОПАСНО! SQL Injection
async function getUsers(sortField, sortOrder) {
  const query = `
    SELECT * FROM users 
    ORDER BY ${sortField} ${sortOrder}
  `;
  return db.query(query);
}

// Атакующий может передать:
// sortField = "id; DROP TABLE users; --"
// Результат: SQL будет скомпрометирован

Правильное решение — белый список:

const ALLOWED_FIELDS = ['id', 'name', 'email', 'createdAt'];
const ALLOWED_ORDERS = ['ASC', 'DESC'];

async function getUsers(sortField, sortOrder) {
  // Валидация
  if (!ALLOWED_FIELDS.includes(sortField)) {
    throw new BadRequestError(`Invalid sort field: ${sortField}`);
  }
  if (!ALLOWED_ORDERS.includes(sortOrder.toUpperCase())) {
    throw new BadRequestError(`Invalid sort order: ${sortOrder}`);
  }
  
  // Теперь безопасно
  const query = `
    SELECT * FROM users 
    ORDER BY ${sortField} ${sortOrder}
  `;
  return db.query(query);
}

С ORM (TypeORM/Sequelize) это проще:

// TypeORM
const query = userRepository.createQueryBuilder('user');

if (ALLOWED_FIELDS.includes(sortField)) {
  query.orderBy(`user.${sortField}`, sortOrder);
}

return query.getMany();

2. Case Sensitivity проблемы

Разные базы данных по-разному обрабатывают регистр:

// PostgreSQL — case-sensitive
// MySQL с utf8_general_ci — case-insensitive
// SQLite — depends на конфигурацию

// Клиент отправляет: "Name" (большая буква)
// Сервер ищет: "name" (маленькая)
// Результат: ошибка 400 Bad Request

Решение — нормализация:

function normalizeSortField(field) {
  // Конвертируем в camelCase
  return field.toLowerCase();
}

const normalizedField = normalizeSortField(req.query.sort);
if (!ALLOWED_FIELDS.includes(normalizedField)) {
  throw new BadRequestError();
}

3. Производительность при сортировке больших таблиц

Без индекса ORDER BY может быть очень медленным:

// Если нет индекса на createdAt — это Full Table Scan
SELECT * FROM users ORDER BY createdAt DESC LIMIT 10;
// На таблице из 10 млн записей это может быть 5+ секунд

Решение:

1. Создай индексы на часто используемые поля:

CREATE INDEX idx_users_created_at ON users(createdAt DESC);
CREATE INDEX idx_users_name ON users(name ASC);
CREATE INDEX idx_users_email ON users(email ASC);

1. Ограничивай результаты:

async function getUsers(sortField, sortOrder, limit = 50, offset = 0) {
  // Максимум 1000 результатов
  const MAX_LIMIT = 1000;
  if (limit > MAX_LIMIT) limit = MAX_LIMIT;
  
  return db.query(`
    SELECT * FROM users 
    ORDER BY ${sortField} ${sortOrder}
    LIMIT ${limit} OFFSET ${offset}
  `);
}

4. Проблемы с множественной сортировкой

Порядок полей в ORDER BY критичен для производительности:

-- Плохо: полная таблица → сортировка
SELECT * FROM users 
ORDER BY status, createdAt DESC;

-- Хорошо: используется индекс (status, createdAt)
CREATE INDEX idx_users_status_created 
ON users(status, createdAt DESC);

Проблема с параметризованной сортировкой:

// Клиент отправляет: "status,createdAt"
// Это может быть не оптимально, если индекс (createdAt, status)

// Решение: 
// 1. Задай фиксированный порядок сортировки на сервере
// 2. Или документируй для клиента, какой порядок эффективнее

5. Сортировка по полям с NULL значениями

NULL обрабатывается по-разному в разных БД:

-- PostgreSQL, MySQL: NULL идёт в конец при ASC
SELECT * FROM users ORDER BY phone ASC;
-- NULL, NULL, '123...', '456...'

-- SQL Server: NULL идёт в начало при ASC
-- Oracle: NULL идёт в конец при ASC (как PostgreSQL)

Решение — явная обработка:

// PostgreSQL
const query = `
  SELECT * FROM users 
  ORDER BY phone IS NULL, phone ${sortOrder}
`;

// MySQL
const query = `
  SELECT * FROM users 
  ORDER BY ISNULL(phone), phone ${sortOrder}
`;

6. Сортировка по JOIN полям

Сортировка по связанным таблицам может вызвать проблемы:

// ОПАСНО: может вернуть дубликаты
const query = `
  SELECT u.* FROM users u
  LEFT JOIN posts p ON u.id = p.user_id
  ORDER BY p.created_at DESC
`;

// Если у пользователя 10 постов, он появится 10 раз

Решение:

// 1. Используй DISTINCT
const query = `
  SELECT DISTINCT u.* FROM users u
  LEFT JOIN posts p ON u.id = p.user_id
  ORDER BY MAX(p.created_at) DESC
  GROUP BY u.id
`;

// 2. Или сортируй по полю основной таблицы
const query = `
  SELECT u.* FROM users u
  LEFT JOIN posts p ON u.id = p.user_id
  ORDER BY u.created_at DESC
`;

7. Сортировка с фильтрацией — индексы не работают

Неправильный порядок полей в WHERE и ORDER BY:

-- Индекс (status, createdAt)
-- Плохо: WHERE не использует индекс, затем сортировка
SELECT * FROM users 
WHERE createdAt > NOW() - INTERVAL 1 MONTH
ORDER BY status, createdAt;

-- Хорошо: используется индекс полностью
SELECT * FROM users 
WHERE status = 'active'
ORDER BY createdAt DESC;

8. Сортировка и пагинация — cursor-based vs offset

Offset-based пагинация медленна для больших offset:

// Медленно на странице 1000 (offset 10000)
SELECT * FROM users 
ORDER BY createdAt DESC
LIMIT 50 OFFSET 10000;
// БД должна обработать первые 10050 строк

// Быстро: cursor-based
SELECT * FROM users 
WHERE createdAt < ?
ORDER BY createdAt DESC
LIMIT 50;
// БД начинает сразу с нужной позиции

9. Сортировка с преобразованием типов

Сортировка работает неправильно, если типы не совпадают:

// Если age — строка, а не число
// Сортировка: "10", "100", "2", "20" (лексикографическая)
// Ожидается: 2, 10, 20, 100 (числовая)

// Решение: явное преобразование
const query = `
  SELECT * FROM users 
  ORDER BY CAST(age AS INTEGER) DESC
`;

10. Sортировка с locale-aware сравнением

Для сортировки строк по русскому, английскому и т.д.:

// По умолчанию сортировка может быть неправильной
// PostgreSQL
SELECT * FROM users 
ORDER BY name COLLATE "ru_RU.UTF-8" ASC;

// MySQL
SELECT * FROM users 
ORDER BY name COLLATE utf8mb4_unicode_ci ASC;

Чеклист при реализации параметризованной сортировки

• Белый список полей — никогда не доверяй клиенту
• Валидация direction — только ASC/DESC
• Нормализация input — toLowerCase(), trim()
• Индексы на DB — EXPLAIN ANALYZE твой query
• Ограничения на результаты — MAX_LIMIT = 1000
• Обработка NULL — явная логика для каждой БД
• Тесты производительности — при 1млн+ записей
• Документация — какие поля можно сортировать
• Мониторинг — slow query log в продакшене
• Graceful degradation — если индекс не помогает, вернуть ошибку