Innodb autoincrement per custom column, bad concurrency - mysql

Question

We have table MySql 5.5:
CREATE TABLE IF NOT EXISTS `invoices` (
`id` varchar(36) NOT NULL,
`client_id` smallint(4) NOT NULL,
`invoice_number` int(11) DEFAULT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `client_id_2` (`client_id`,`invoice_number`),
KEY `client_id` (`client_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
We insert data into that table like this:
INSERT INTO `invoices` ( `id` , `client_id` , `invoice_number` )
VALUES (
UUID(),
10 ,
( SELECT (MAX(`invoice_number`) +1) as next_invoice_number FROM `invoices` WHERE `client_id` = 10 )
);
"10" is client_id value.
It works but, it has bad concurrency. How can I have working solution, which has good concurrency?
Composite-primary-key auto increment is not a solution. We need autoincrement per client_id value. Composite-primary-key auto increment gives autoincrement all over table not per client_id column value.

Answer 1

Not sure what you meant by bad concurrency here. Though every DML operation runs on implicit transaction, you can as well wrap it in a explicit transaction block by using begin transaction ... end construct.

Answer 2

It seems that mysql is really locking the whole table on insert into ... select.
Below a strategy which is working for us (for a similar problem) in pseudocode
function insert_user(){
begin_transaction
next_invoice_number = select_max_invoice_number + 1
insert_user(next_invoice_number)
end_transaction
}
function perform_insert(){
try
insert_user
catch RecordNotUniqueError
perform_insert
end
}
This requires performing a query in some high level programming language.
You basically start a tansaction, where you first perform a query to read the next invoice number for the user. Afterwards you perform the insert query with next_invoice_number and hope for the best. In case there is a concurrent process trying to insert with the same invoice number for the same user, the transaction will fail for one of the processes. It can then try to repeat it. At the end there should be no concurrent operation for the same invoice number and every transaction will succeed.

Answer 3

I see a number of issues here.
First, for each invoice registration you are scanning the same table to find what the next invoice number should be used for this particular customer.
A far faster solution is to have a table with two columns: Customer_ID (key) and Last invoice ID.
Whenever you need to register a new invoice, you simply get-and-update the new invoice number from this new table and use it in the insert.
Second, what makes you think that the operation you are showing in your example should not lock the table?
Since this is happening only sometimes, the best solution is to minimize the probability of a collision, and the approach presented here will certainly do that.

Answer 4

Reformulate the query this way. This is probably simpler and faster.
INSERT INTO `invoices` ( `id` , `client_id` , `invoice_number` )
SELECT UUID(),
10 ,
MAX(`invoice_number`) +1
FROM `invoices`
WHERE `client_id` = 10;
Is this in a transaction by itself? With autocommit=1?
Or is this a part of a much larger set of commands? And possibly they are part of what is leading to the error?
How will you subsequently get the UUID and/or invoice_number for the client? Doesn't the application need to display them and/or store them in some other table?