Can I blindly replace all mysql_ functions with mysqli_?

The short answer is no, the functions are not equivalent.

The good news is there is a converter tool that will help you if you've got a lot of calls/projects to change. This will allow your scripts to work right away.

https://github.com/philip/MySQLConverterTool

It's a forked version of the Oracle original version, and it's kosher.

That said, it's not too difficult to update your code, and you might want to migrate to an object orientated methodology anyway ...

1) The Connection

For all intents and purposes, you need a new connection function that saves the connection as a PHP variable, for example;

$mysqli = new mysqli($host,$username,$password,$database);

Notice I've saved the connection to $mysqli. You can save to $db or whatever you like, but you should use this throughout your code to reference the connection.

Remember to check for a connection error though;

if ($mysqli->connect_errno) echo "Error - Failed to connect to MySQL: " . $mysqli->connect_error;

2) The Query

Note: You should protect against SQL injection with prepared statements, which are available in MySQLi. Take a look at How can I prevent SQL injection in PHP?, but I'm just going to cover the basics here.

You now have to include the connection as an argument in your query, and other mysqli_ functions. In procedural code it's the first argument, in OO you write it like a class method;

Procedural:

$result = mysqli_query($mysqli,$sql);

OO:

$result = $mysqli->query($sql);

3) Fetch Result

The fetching of the result is similar to the old mysql_ function in procedural;

while($row = mysqli_fetch_assoc($result))

but as $result is now an object in mysqli, you can use the object function call;

while($row = $result->fetch_assoc())

4) Close Connection

So as before, you need to include the connection in the close function; as an argument in procedural;

mysqli_close($mysqli);

and as the object that you run the function on in OO;

$mysqli->close();

I would be here forever if I went through them all, but you get the idea. Take a look at the documentation for more information. Don't forget to convert any connection close, result release, or error and row counting functions you have.

The basic rule of thumb is for functions that use the database connection, you need to include it in the function now (either as the first argument in procedural, or the object you use to call the function in OO), or for a result set you can just change the function to mysqli_ or use the result set as the object.

Perhaps you could create an indexing table which provides a sequential key relating to the key in your target table. Then you can join this indexing table to your target table and use a where clause to more efficiently get the rows you want.

#create table to store sequences
CREATE TABLE seq (
   seq_no int not null auto_increment,
   id int not null,
   primary key(seq_no),
   unique(id)
);

#create the sequence
TRUNCATE seq;
INSERT INTO seq (id) SELECT id FROM mytable ORDER BY id;

#now get 1000 rows from offset 1000000
SELECT mytable.* 
FROM mytable 
INNER JOIN seq USING(id)
WHERE seq.seq_no BETWEEN 1000000 AND 1000999;

For warnings to be "flagged" to PHP natively would require changes to the mysql/mysqli driver, which is obviously beyond the scope of this question. Instead you're going to have to basically check every query you make on the database for warnings:

$warningCountResult = mysql_query("SELECT @@warning_count");
if ($warningCountResult) {
    $warningCount = mysql_fetch_row($warningCountResult );
    if ($warningCount[0] > 0) {
        //Have warnings
        $warningDetailResult = mysql_query("SHOW WARNINGS");
        if ($warningDetailResult ) {
            while ($warning = mysql_fetch_assoc($warningDetailResult) {
                //Process it
            }
        }
    }//Else no warnings
}

Obviously this is going to be hideously expensive to apply en-mass, so you might need to carefully think about when and how warnings may arise (which may lead you to refactor to eliminate them).

For reference, MySQL SHOW WARNINGS

Of course, you could dispense with the initial query for the SELECT @@warning_count, which would save you a query per execution, but I included it for pedantic completeness.