Small Queries Work, Large Ones Fail: Which Packet Size Is It?
SQL Server driver packets, MySQL message limits and an IP path's MTU are different units. A size-dependent failure does not make them interchangeable.
Small queries return, large ones hang or drop, and the first instinct is that something about packet size is wrong. That instinct is usually right and almost always aimed at the wrong layer. Three settings share the word packet and measure three unrelated things: a database driver's transport packaging, a database server's message limit, and the IP path's maximum transmission unit. Adjusting one to fix a symptom caused by another is how a five-minute problem becomes a week of tuning. The order below is the one that has cost me the least time.
Three layers, one shared word
Each row below is a different unit with a different owner, and none of them can be reasoned about from the others. A database message can span many TCP segments and many IP packets, so increasing its permitted size does not enlarge the path, and reducing a driver setting is not the same operation as changing an interface MTU. The word appears in three different configuration files, which is why searching for it returns three unrelated answers. Read the error text first, then decide which file to open.
| Setting or observation | Unit it describes |
|---|---|
| SQL Server client network packet setting | The provider's transport packaging for that connection |
| MySQL communication packet limit | A database message, such as one statement, row or replication event |
| IP path MTU | The largest IP packet the path carries without fragmentation handling |
Write down which layer the failing operation belongs to before you open a configuration file. The error text usually says so, and the error text is the part people skip.
Identify the provider before you change its setting
For SQL Server, record the application, the driver or provider name, the version, and the effective connection configuration. A diagnostic script and a desktop application can reach the same server through different providers, so a setting that helps one proves nothing about the other. Provider defaults differ, and a similarly named connection-string field is not evidence that every provider interprets it the same way.
Do not swap a maintained driver for a legacy one just because an old workaround used its syntax. Current documentation discourages new development against those older components, and inheriting their limitations is a poor trade for one setting.
Message rejection is not a path stall
On MySQL 8.4, the communication-packet documentation describes an oversized statement, row or binary-log event being rejected against the applicable limit, and both client and server limits can matter. That is a rejection at the database layer, not a statement that the network must carry a gigantic IP packet. Read the actual error and the shape of the offending message: a large result made of many small rows is a different case from one enormous row, and they fail differently.
MariaDB installations need their own version's documented limits and diagnostics. Copying MySQL defaults onto MariaDB is guessing with extra steps.
What path evidence actually looks like
A path-size problem has its own fingerprint: a reproducible size-dependent transport failure along one particular route and address family, with the tunnel's overhead in play and discovery feedback behaving as the path allows. A timeout alone does not distinguish it from a slow query, a driver bug, or a server-side limit, and treating a timeout as proof of MTU problems sends you to the wrong layer with confidence.
If you do test the path, keep the destination, account and workload fixed so the only variable is the size you are probing. A test where three things changed tells you nothing about which one mattered.
Change one documented variable, then record it
Keep the destination, account, provider and workload constant, record the original value, apply one supported change, and record the result. A smaller setting that makes one test succeed is useful evidence about that tested stack; it is not a universal optimum and it does not establish what caused the original failure. Those are different claims, and only the first one is supported by a single experiment.
Resolve the identified limit at its own layer, then note which layer it was. The note is what stops the next person from tuning the driver because the path was the problem.