Dual procedural and object-oriented interface

The mysqli extension features a dual interface. It supports the procedural and object-oriented programming paradigm.

Users migrating from the old mysql extension may prefer the procedural interface. The procedural interface is similar to that of the old mysql extension. In many cases, the function names differ only by prefix. Some mysqli functions take a connection handle as their first argument, whereas matching functions in the old mysql interface take it as an optional last argument.

Example #1 Easy migration from the old mysql extension

<?php
$mysqli = mysqli_connect("example.com", "user", "password", "database");
$result = mysqli_query($mysqli, "SELECT 'Please do not use the deprecated mysql extension for new development. ' AS _msg FROM DUAL");
$row = mysqli_fetch_assoc($result);
echo $row['_msg'];

$mysql = mysql_connect("example.com", "user", "password");
mysql_select_db("test");
$result = mysql_query("SELECT 'Use the mysqli extension instead.' AS _msg FROM DUAL", $mysql);
$row = mysql_fetch_assoc($result);
echo $row['_msg'];

以上例程会输出：

Please do not use the deprecated mysql extension for new development. Use the mysqli extension instead.

The object-oriented interface

In addition to the classical procedural interface, users can choose to use the object-oriented interface. The documentation is organized using the object-oriented interface. The object-oriented interface shows functions grouped by their purpose, making it easier to get started. The reference section gives examples for both syntax variants.

There are no significant performance differences between the two interfaces. Users can base their choice on personal preference.

Example #2 Object-oriented and procedural interface

<?php

$mysqli = mysqli_connect("example.com", "user", "password", "database");

$result = mysqli_query($mysqli, "SELECT 'A world full of ' AS _msg FROM DUAL");
$row = mysqli_fetch_assoc($result);
echo $row['_msg'];

$mysqli = new mysqli("example.com", "user", "password", "database");

$result = $mysqli->query("SELECT 'choices to please everybody.' AS _msg FROM DUAL");
$row = $result->fetch_assoc();
echo $row['_msg'];

以上例程会输出：

A world full of choices to please everybody.

The object oriented interface is used for the quickstart because the reference section is organized that way.

Mixing styles

It is possible to switch between styles at any time. Mixing both styles is not recommended for code clarity and coding style reasons.

Example #3 Bad coding style

<?php

$mysqli = new mysqli("example.com", "user", "password", "database");

$result = mysqli_query($mysqli, "SELECT 'Possible but bad style.' AS _msg FROM DUAL");

if ($row = $result->fetch_assoc()) {
    echo $row['_msg'];
}

以上例程会输出：

Possible but bad style.

See also

User Contributed Notes

Anonymous 15-Jan-2016 10:58
I don't know whether I can put my opinion here, but yet...

I don't think that mixing styles is so bad idea. Yes, maybe it isn't good when working in a team, but if you work on a code on your own and it's convenient for you - why not?

For example, I prefer the OO style generally. But when it comes to setting connection, the procedural style provides opportunity to use easy 'or' syntax:

<?php
$connection = @mysqli_connect('localhost', 'root', '1234', 'db') or die('Connect Error (' . mysqli_connect_errno() . ') ' . mysqli_connect_error());
?>

which is more convenient for me than:

<?php
$connection = @new mysqli('localhost', 'root', '1234', 'db');
if ($conn->connect_errno) {
    die('Connect Error (' . $connection->connect_errno() . ') ' . $connection->connect_error());
}
?>

So why shouldn't I use the procedural style when setting connection?
Anonymous 06-Jan-2015 11:36
Just want to add that both procedural mysqli_connect_errno and mysqli_connect_error DON'T accept any arguments!
http://php.net/manual/de/mysqli.connect-errno.php
http://php.net/manual/de/mysqli.connect-error.php
"int mysqli_connect_errno ( void )"
"string mysqli_connect_error ( void )"
It clearly states "void" there.

Adding the mysqli-Instance as a parameter makes it look like it pulls the error-number out of the provided instance, which is not actually happening. This could end in a hard to detect bug when connecting to multiple SQL servers.
And it is confusing for beginners.