在多租户 MySQL 数据库中生成（和保存）增量发票编号的最佳方法

Question

I have found two different ways to, first, get the next invoice number and, then, save the invoice in a multi-tenant database where, of course, each tenant will have his own invoices with different incremental numbers.

• My first (and actual) approach is this (works fine):

1. Add a new record to the invoices tables. No matter the invoice number yet (for example, 0, or empty)
2. I get the unique ID of THAT created record after insert
3. Now I do a "SELECT table where ID = $lastcreatedID **FOR UPDATE**"
4. Here I get the latest saved invoice number with "SELECT @A:=MAX(NUMBER)+1 FROM TABLE WHERE......"
5. Finally I update the previously saved record with that invoice number with an "UPDATE table SET NUMBER = $mynumber WHERE ID = $lastcreatedID"

This works fine, but I don't know if the "for update" is really needed or if this is the correct way to do this in a multi-tenant DB, due to performance, etc.

• The second (and simpler) approach is this (and works too, but I don't know if it is a secure approach):

1. INSERT INTO table (NUMBER,TENANT) SELECT COALESCE(MAX(NUMBER),0)+1,$tenant FROM table WHERE....
2. That's it

Both methods are working, but I would like to know the differences between them regarding speed, performance, if it may create duplicates, etc.

Or... is there any better way to do this?

I'm using MySQL and PHP. The application is an invoice/sales cloud software that will be used by a lot of customers (tenants).

Thanks

Answer 1

Regardless of if you're using these values as database IDs or not, re-using IDs is virtually guaranteed to cause problems at some point. Even if you're not re-using IDs you're going to run into the case where two invoice creation requests run at the same time and get the same MAX()+1 result.

To get around all this you need to reimplement a simple sequence generator that locks its storage while a value is being issued. Eg:

CREATE TABLE client_invoice_serial (
  -- note: also FK this back to the client record
  client_id INTEGER UNSIGNED NOT NULL PRIMARY KEY,
  serial INTEGER UNSIGNED NOT NULL DEFAULT 0
);

$dbh = new PDO('mysql:...');
/* this defaults to 'on', making every query an implicit transaction. it needs to
be off for this. you may or may not want to set this globally, or just turn it off
before this, and back on at the end. */
$dbh->setAttribute(PDO::ATTR_AUTOCOMMIT,0);
// simple best practice, ensures that SQL errors MUST be dealt with. is assumed to be enabled for the below try/catch.
$dbh->setAttribute(PDO::ATTR_ERRMODE_EXCEPTION,1);

$dbh->beginTransaction();
try {
    // the below will lock the selected row
    $select = $dbh->prepare("SELECT * FROM client_invoice_serial WHERE client_id = ? FOR UPDATE;");
    $select->execute([$client_id]);

    if( $select->rowCount() === 0 ) {
        $insert = $dbh->prepare("INSERT INTO client_invoice_serial (client_id, serial) VALUES (?, 1);");
        $insert->execute([$client_id]);
        $invoice_id = 1;
    } else {
        $invoice_id = $select->fetch(PDO::FETCH_ASSOC)['serial'] + 1;
        $update = $dbh->prepare("UPDATE client_invoice_serial SET serial = serial + 1 WHERE client_id = ?");
        $update->execute([$client_id])
    }
    $dbh->commit();
} catch(\PDOException $e) {
    // make sure that the transaction is cleaned up ASAP, then let the exception bubble up into your general error handling.
    $dbh->rollback();
    throw $e; // or throw a more pertinent error/exception of your choosing.
}
// both committing and rolling back will release the lock

At a very basic level this is what MySQL is doing in the background for AUTOINCREMENT columns.

Answer 2

Do not use MAX(id)+1 . It will, someday, bite you. There will be two invoices with the same number, and it will take us a few paragraphs to explain why it happened.

Instead, use AUTO_INCREMENT the way it is intended.

INSERT INTO Invoices (id, ...) VALUES (NULL, ...);
SELECT LAST_INSERT_ID();   -- specific to the conne ction

That is safe even when multiple connections are doing the same thing. No FOR UPDATE , no BEGIN , etc is necessary. (You may want such for other purposes.)

And, never delete rows. Instead, use the standard business practice of invalidating bad invoices. Imagine being audited.

All that said, there is still a potential problem. After a ROLLBACK or system crash, an id may be "burned". Also things like INSERT IGNORE allocate the id before checking to see whether it will be needed.

If you can live with the caveats, use AUTO_INCREMENT .

If not, then create a 1-row, 2-column table to simulate a sequence number generator: http://mysql.rjweb.org/doc.php/index_cookbook_mysql#sequence

Or use MariaDB's SEQUENCE

Answer 3

Both the approaches do work, but each with its own demerits in high traffic situations.

The first approach runs 3 queries for every invoice you create, putting extra load on your server.

The second approach can lead to duplicates in events where two invoices are generated with very little time difference (such that the SELECT query return same max number for both invoices).

Both the approaches may lead to problems in high traffic conditions.

Two solutions to the problems are listed below:

1. Use generated columns : Mysql supports generated columns, which are basically derived using other column values for each row. Refer this

2. Calculate invoice number on the fly : Since you're using the primary key as part of the invoice, let the DB handle generating unique primary keys, and then generate invoice numbers on the fly in your business logic using the id for each invoice.