На мой взгляд, вопрос MySQL имеет два ответа.Подготовленный протокол оператора определяет 2-байтовое короткое число со знаком для описания количества параметров, которые будут получены с сервера.Сначала клиент вызывает COM_STMT_PREPARE , для которого он получает COM_STMT_PREPARE ответ в случае успеха.
Документация для состояний ответа:
Если num_params> 0, последуют еще 0 пакетов:
Блок определения параметров
Учитывая, что num_params может быть максимум 2 ^ 16 (подписанный шорт), из этого следует, что это предел параметров и как моя компанияимеет собственный драйвер MySQL, который мы выбрали, чтобы следовать этому правилу при его реализации, и возникает исключение, если превышен предел.
Однако COM_STMT_PREPARE фактически не возвращает ошибку, если вы отправляете больше этого числапараметры.Значение num_params на самом деле составляет всего 2 ^ 16, и последуют дополнительные параметры.Я не уверен, является ли это ошибкой, но в документации к протоколу это поведение не описывается.
До тех пор, пока у вас есть способ узнать количество параметров на стороне клиента (client_num_params, если выбудет), вы могли бы реализовать свой клиент MySQL таким образом, чтобы он ожидал увидеть client_num_params x Protocol::ColumnDefinition.Вы также можете наблюдать за EOF_Packet, но это фактически отправляется, только если CLIENT_DEPRECATE_EOF не включено.
Интересно также отметить, что после num_params есть зарезервированный байт, указывающий, что разработчики протокола, вероятно, хотеливозможность сделать это 24-битное число, что позволяет около 8,3 миллиона параметров.Для этого также потребуется дополнительный флаг возможностей клиента.
Подводя итог:
- Документация по протоколу клиент / сервер, по-видимому, указывает, что максимальное количество параметров может быть 32768
- Сервер, похоже, не заботится, отправляете ли вы больше, но это не документировано и может не поддерживаться в будущих выпусках.Я очень сомневаюсь, что это произойдет, потому что это сломает несколько драйверов, включая собственный ADO.NET Connector от Oracle.