The basic natives of SQLX - AMXX
SQL_MakeDbTuple (or simple stock version, SQL_MakeStdTuple) - This creates a variable that holds information about a database. It does not connect to the database. This is so you don't have to keep retrieving cvar info on every connection. You do not have to free these handles, although it is a good idea if you create them dynamically.
SQL_Connect - Connects to a database and returns a new Handle, or Empty_Handle on failure.
SQL_PrepareQuery - Prepares a query for execution, and returns a new Handle to the query.
SQL_Execute - Executes a prepared query, and returns 0 on failure (1 on success).
SQL_MoreResults - Returns 1 if there are more results in the query result queue, 0 if none.
SQL_ReadResult - Reads the current row result by the column's numerical index, similar to dbi_field/dbi_result.
SQL_NextRow - Advances to the next result row. Compatibility Warning: This does not need to be called first! Unlike dbi_nextrow, the query is automatically at the first row. If you call SQL_NextRow before SQL_ReadResult, your are actually skipping a row.
SQL_FreeHandle - Frees a Handle. You must do this or else memory will leak.
SQL_ThreadQuery - Places a query and connection info into a threaded queue. In another thread, the connection is established, the query is executed, and the connection is dropped. The query results are then posted back into the main thread and given to the plugin on the next server-frame.
Note that while powerful, the mechanism is very simplistic. Similar to set_task, you must differentiate multiple queries having the same callback by packing binary data into an array. Furthermore, you can only make one query at a time, since the queue is "push one, resolve one, pop one." If you plan on making five queries in a row in order to get aggregate information about a player, you must make each of these five queries in separate stages, and you must also take into account asynchronous factors such as the player dropping during the middle of a query. (One way to do this is to pack the player's authid and client index into the callback data and verify it when the query finishes.)
Note that you should currently not call this native during plugin_end(). The backend threader freezes the query queue at this time and flushes all remaining queries back to the main thread. It is likely your plugin will simply deadlock (freeze idly). Even if this is corrected, there is no reason to use threaded queries in plugin_end() anyway, because all remaining threaded queries are executed as non-threaded before the mapchanges.