EE_DEBUG_INFO (error 66) is an internal MySQL debug error added in 8.0.13 that surfaces when the server hits a code path meant only for diagnostic builds.
MySQL Error 66: EE_DEBUG_INFO appears when a debug-compiled MySQL 8.0.13+ server encounters an unexpected state and emits internal diagnostics. Resolve it by reviewing the server error log, validating tables, and running a production build or upgrading to a stable release.
%s. EE_DEBUG_INFO was added in 8.0.13.
MySQL raises error 66 with the condition name EE_DEBUG_INFO when the server, compiled with debug flags, reaches a code branch intended only for diagnostic output. The message usually reads “%s. EE_DEBUG_INFO was added in 8.0.13.”
This error is classified as a global runtime error and is rarely exposed to clients in production environments.
It signals an internal inconsistency that developers wanted to trace during debugging.
The error emerges during query execution, startup, or shutdown when the server detects an unexpected state in storage engines, metadata caches, or replication logic.
Because the branch is guarded by debug macros, it is seen mainly on servers built with WITH_DEBUG enabled.
Users connecting through any client, including Galaxy’s SQL editor, will receive the error text immediately after the failing statement.
Internal code assertions failing in debug builds trigger EE_DEBUG_INFO. Common hotspots are corrupted tables, corrupted redo logs, and plugin API misuse.
Developers occasionally add temporary debug prints that call my_error(EE_DEBUG_INFO, ...).
Running mismatched client and server versions or using experimental plugins can widen the chance of hitting these debug paths.
Start by inspecting the MySQL error log for a stack trace or assertion description. The log pinpoints the file and line that raised EE_DEBUG_INFO.
Next, verify data integrity with CHECK TABLE or mysqlcheck. Repair any corruption found.
If the problem persists, migrate to a production build compiled without debug flags or upgrade to the latest GA release where the offending debug call is removed.
Scenario: EE_DEBUG_INFO after restarting the server. Solution: Review innodb_redo.log integrity, restore from backup, or recreate redo logs.
Scenario: Error appears only on a single table query. Solution: Run CHECK TABLE tbl_name; then REPAIR TABLE tbl_name if MyISAM, or ALTER TABLE ...
FORCE for InnoDB.
Run production workloads on non-debug builds. Debug binaries are slower and contain extra assertions meant for development.
Keep MySQL upgraded and apply minor releases promptly. Newer versions often remove debug stubs that escaped into GA.
ER_ASSERT_FAILURE: Similar internal assertion but always compiled in; fix by upgrading and checking corruption.
ER_SERVER_SHUTDOWN: Raised when a fatal internal error forces shutdown; analyze error log like EE_DEBUG_INFO.
.
No. It indicates the MySQL server executed a debug-only code path. It is usually a bug or data corruption, not a SQL mistake.
Ignoring it risks data integrity. Always investigate the cause and plan to upgrade or fix corruption.
Galaxy surfaces the error quickly and lets you share logs with admins, but the root cause must be fixed on the MySQL server.
No. EE_DEBUG_INFO is raised independently of logging settings.
.avif)
.avif){kind=logo}
