G
G
Grigory Vasilkov2017-09-26 18:16:53
MySQL
Grigory Vasilkov, 2017-09-26 18:16:53

Whether there is a sense from the point of view of optimization to do in SQL a column second_id (unique, primary)?

Continuing the issue of optimizing the table with goods - understanding that records in the table occur mainly as INSERT IGNORE, an AUTO_INCREMENT overflow situation will soon arise. Again, I would like to be able to reset the id by re-sorting the database once, without spending time on it.
If I have
id, category_id, articul
id (pk, auto)
category_id, articul (unique)
Does it make sense to make second_id, which will essentially be md5() from category_id, articul or another hash, to be associated with another table by it? Or is it better to use both fields for communication in the second table (there will be a double of information with foreign keys)?
I'm talking about something like this:

SELECT @product_id := MAX(product_id) FROM products;
UPDATE products t1
JOIN (
  SELECT @product_id := (@product_id + 1) `product_id` products WHERE product_id IS NULL
) t2 ON t2.id = t1.id
SET t1.product_id = t2.product_id;

Answer the question

In order to leave comments, you need to log in

2 answer(s)
A
Alexander Aksentiev, 2017-09-26
@gzhegow

soon there will be an overflow situation

shoot yourself in the foot or shoot yourself in the foot
Why not simply change the PK to a normal sized integer?
What is it like now that there will be an overflow soon?
By default, it's done by 2 lard, int(10) or 11 or something like that. Almost everywhere.
Well, do not forget to correct all referring tables.

D
d-stream, 2017-09-27
@d-stream

Here there is a conceptual eversion with fur inside the concept of primary

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question