English
English
<span><span><span class="hljs-meta"><?php</span></span><span>
</span><span><span class="hljs-comment">// This document aims to explore the best practices for using the mysqli::dump_debug_info function in PHP in combination with MySQL debug mode.</span></span><span>
</span><span><span class="hljs-comment">// No modification needed here, this section is for article positioning and testing purposes only.</span></span><span>
<p></span>// Setting up the database connection (example only)<br>
$mysqli = new mysqli("localhost", "user", "password", "database");</p>
<p>// Ensure connection is successful<br>
if ($mysqli->connect_error) {<br>
</span>die("Connection failed: " . $mysqli->connect_error);<br>
}</p>
<p></span>// Example usage of dump_debug_info<br>
$mysqli->dump_debug_info();<br>
</span>?><br>
<hr><br>
</span>In everyday development, interactions between PHP programs and MySQL often hide a lot of debugging information, especially when dealing with high concurrency, complex queries, or unexplained performance bottlenecks. mysqli::dump_debug_info() is a relatively lesser-known but very useful debugging function that helps transmit connection status information from the PHP layer to the MySQL server. However, calling this function alone usually makes it difficult to observe its effect. Only when combined with MySQL's debug mode can it truly deliver its value.
mysqli::dump_debug_info() is a method in PHP’s mysqli class designed to send a debug information request to the MySQL server. Its function signature is as follows:
<span><span><span class="hljs-keyword">bool</span></span><span> mysqli::</span><span><span class="hljs-variable constant_">dump_debug_info</span></span><span> ( </span><span><span class="hljs-keyword">void</span></span><span> )
</span></span>Once called, the MySQL server writes the current connection’s debug information into its log file, provided the server’s debug feature is enabled.
For dump_debug_info() to be effective, you first need to enable debugging on the MySQL server side. Here’s how:
Edit the Configuration File
Open your my.cnf or my.ini file and add the following lines (adjust paths according to your system):
<span><span><span class="hljs-section">[mysqld]</span></span><span>
</span><span><span class="hljs-attr">log_output</span></span><span>=FILE
</span><span><span class="hljs-attr">general_log</span></span><span>=1
</span><span><span class="hljs-attr">general_log_file</span></span><span>=/var/log/mysql/general.log
</span></span>If you require more granular debugging, you can start MySQL with the --debug option, for example:
<span><span><span class="hljs-attribute">mysqld</span></span><span> --</span><span><span class="hljs-literal">debug</span></span>=d:t:i:o,/tmp/mysql_debug.log
</span></span>Restart the MySQL Service
<span><span>sudo systemctl restart mysql
</span></span>Check Log File Permissions
Ensure MySQL has write permissions for the log files, especially under /tmp or /var/log/mysql/.
Here are some practical scenarios demonstrating how to use dump_debug_info() for debugging:
If you suspect some connections are not properly closed or resources are not released after execution, call it after a series of database operations:
<span><span><span class="hljs-variable">$mysqli</span></span><span>-></span><span><span class="hljs-title function_ invoke__">query</span></span><span>(</span><span><span class="hljs-string">"SELECT * FROM users WHERE id = 1"</span></span><span>);
</span><span><span class="hljs-variable">$mysqli</span></span><span>-></span><span><span class="hljs-title function_ invoke__">dump_debug_info</span></span>();
</span></span>This causes the MySQL log to record the internal state of the connection, helping analyze issues like resource leaks.
For batch updates or data-cleaning scripts, call dump_debug_info() at each stage to track the current connection execution path on the server side. For example:
<span><span><span class="hljs-keyword">foreach</span></span><span> (</span><span><span class="hljs-variable">$userIds</span></span><span> </span><span><span class="hljs-keyword">as</span></span><span> </span><span><span class="hljs-variable">$id</span></span><span>) {
</span><span><span class="hljs-variable">$mysqli</span></span><span>-></span><span><span class="hljs-title function_ invoke__">query</span></span>(</span><span><span class="hljs-string">"UPDATE users SET status = 'active' WHERE id = <span class="hljs-subst">$id</span></span></span><span>");
</span><span><span class="hljs-variable">$mysqli</span></span><span>-></span><span><span class="hljs-title function_ invoke__">dump_debug_info</span></span>(); </span><span><span class="hljs-comment">// Writes debug info after each update</span></span><span>
}
</span></span>If slow query logging is enabled, combining dump_debug_info() timestamps can help pinpoint which part of the code triggered the slow query.
Calling dump_debug_info() does not return any data in PHP nor throws exceptions; all debug information appears only in MySQL logs.
It is not recommended to use this function frequently in production as it increases I/O load.
Unlike mysqli_debug(), dump_debug_info() provides a runtime snapshot of the current connection status rather than setting global debug parameters.
Although mysqli::dump_debug_info() is rarely used in most projects, it is an indispensable tool when closely cooperating with DBAs or server teams for troubleshooting. By properly configuring MySQL debug logs and calling this function at critical points, developers can better observe and optimize the interaction between PHP and the database, ultimately improving system stability and performance.
