I created a new MySql table and saw that the auto-increment field starts with a value of 3 and increments by 2. I do a SHOW VARIABLES LIKE 'auto_inc%'; and get this-
auto_increment_increment 2
auto_increment_offset 2
I did some research and found that I need to use-
SET ##auto_increment_increment=1; and
SET ##auto_increment_offset=1;
But my question is, will setting both these values to 1 affect how rows are inserted on other tables with auto-increment fields? Will the new rows inserted on those tables start with an auto-increment id of 1 now? Or will this only affect new tables going forward?
The effect of auto_increment_increment and auto_increment_offset is not per-table, it applies to all tables you insert into.
If you use SET in your own session, the variable will be changed in your session only. The behavior in other sessions will not change. Also if you disconnect and reconnect, your session settings are reset to the global settings.
To make the change global, you need to use SET GLOBAL. But the change will be undone the next time MySQL Server restarts.
To make the change global and persistent, either edit the my.cnf file so the variable is set every time MySQL Server starts, or else in MySQL 8.0 they added a feature so you can now use SET PERSIST so you can change global variables and it will retain the setting after a restart.
You can read more about this:
https://dev.mysql.com/doc/refman/8.0/en/using-system-variables.html
https://dev.mysql.com/doc/refman/8.0/en/set-variable.html
Related
I'm recently installed a new server with a newer MySQL release (from 8.0.13 to 8.0.16) and I have a different behavior while retrieving the next auto increment value of my table.
I was initially using
SHOW TABLE STATUS WHERE `Name` = 'user';
in my previous server it was working perfectly, I was able to retrieve the next auto increment value for the next record, but with the new server the same command is not working properly, the value displayed for auto_increment is not the next one
I have found a post mentioning that it might be due to the cache of the statistics table but on both servers I have
show variables like 'information_schema_stats_expiry';
+---------------------------------+-------+
| Variable_name | Value |
+---------------------------------+-------+
| information_schema_stats_expiry | 86400 |
+---------------------------------+-------+
There is also a solution by disabling the cache of this table by using the command
SET PERSIST information_schema_stats_expiry = 0
but I have two questions:
first: where do I set this information_schema_stats_expiry ? I'm not able to launch this command on a SQL command line, neither in the mysql config file
second: If we disable the cache of this table, is there any issue with the overall database performance ?
I'm not sure why this changed when you upgraded from 8.0.13 to 8.0.16. The documentation says that this variable was added in 8.0.3.
This can be set as a session variable, so you could set it to 0 just in the session that needs to fetch the AUTO_INCREMENT value, and it should bypass the cache. But it won't affect other sessions, so should have minimal overall impact on performance.
SET information_schema_stats_expiry = 0;
SHOW TABLE STATUS WHERE `Name` = 'user';
how do you create a table with an auto_increment_increment of 10 instead of the default of 1
I am using mySQL and mySQL workbench as well.
After creating the table either with the workbench gui or by statements, I have tried this in workbench and it works only when I add a new record from the workbench but not thru my web app. If I use the web app it starts to auto increment by one again...I just want to create the table and set its increment to 10 every time so first item is 10 then second is 20 then 30 and so on.
SELECT Auto_increment FROM information_schema.tables WHERE table_name='items';
SET ##auto_increment_increment=10;
Thanks.
You would need to set the auto_increment_increment=10 globally. The SET command you show only sets it for the current session.
Setting it globally makes it affect every table, not just your items table.
There's no support in MySQL for changing the increment size to a different value for each table.
You can change a global option in MySQL with SET GLOBAL. To make the change persist when the MySQL server is restarted, you must edit the options file. Read:
https://dev.mysql.com/doc/refman/5.6/en/using-system-variables.html
https://dev.mysql.com/doc/refman/5.6/en/option-files.html
I am inserting some data to a database and I have an id column which has auto increment. I updated my xampp server yesterday and now the auto increment is starting from 4, 3, 5 in different tables. It used to work fine before. I did not delete any rows from the table it just starts from those numbers. What is wrong?
ALTER TABLE tablename AUTO_INCREMENT = 1
This will reset your auto increment to start from 1
If you really want to reset this, in phpMyAdmin, open this table, go to Operations and change the value for AUTO_INCREMENT.
You can reset your auto increment ID from the following Command:
ALTER TABLE TABLE_NAME AUTO_INCREMENT = 1;
This will start from 1.
OR
go to LOCALHOST/PHPMYADMIN enter:
select your DB
after choose the specific table than go to Operations an set a number to the Auto increment.
If you really want to reset this, in phpMyAdmin, open this table, go to Operations and change the value for AUTO_INCREMENT.----- this is working for me, i have just done this,
This can be a consequence of using a Galera cluster. By default, it will automatically adjust the auto_increment_increment and auto_increment_offset variables according to the size of the cluster, and when the cluster size changes. This avoids replication conflicts due to auto_increment.
The short answer is not to depend on auto_increment numbers being subsequent, without gaps.
Is it possible to set ft_min_word_len for a certain user (such as by placing a my.cnf file in the user home dir with ft_min_word_len set)? The documentation says I need to restart the server after making this change, but a user does not have access to do that.
I'm working with this now, so to add as a reference for anyone looking at this...
You can use this query in a query
browser or the MySQL prompt to show
the state of ft_min_word_len: "SHOW
VARIABLES LIKE 'ft_min_word_len';"
ft_min_word_len deafults to a value
of '4' and is not by default listed
in "my.cnf". To change it's default
value, add: "ft_min_word_len = 3" to
my.cnf under the [mysqld] section.
After changing the value of
ft_min_word_len, the server must be
restarted.
After changing the value of
ft_min_word_len, any indexes you have
must be rebuilt
A fast way to rebuild an index is to
use this query: "REPAIR TABLE
your_table_name QUICK;" Note:
You're using the name of the table
only, not the name of any indexes.
If you have more than one index
against the 'your_table_name' table,
all of them will be re-built.
No, it's not possible, because it changes how the fulltext indices are built. It takes effect at index generation, not (only) at query time.
FYI: Not only do you have to restart the server, you have to rebuild all your fulltext indices after changing it.
I want to connect and execute one (or sometimes several) SQL statements, and NOT have those replicated to the slaves.
I have no replicate-do or replicate-ignore configs, so I can't use some non-replicated database to send the commands from. And I know about:
set global sql_slave_skip_counter = 1
But that's on the slave. I'd like to be able to run a similar command on the master and have the following N commands not sent out to the slaves (which I guess means not logged in the binlogs, either).
SET sql_log_bin=0 is what you're looking for. Requires SUPER priv., and will turn off logging of commands from your session until you set it back to 1. See http://dev.mysql.com/doc/refman/5.0/en/server-session-variables.html#sysvar_sql_log_bin
SET sql_log_bin=0;
UPDATE ... ;
INSERT ... ;
DELETE ... ;
SET sql_log_bin=1 ;
BE CAREFUL.....!
SET sql_log_bin=0;
Master MySQL server automatically set this 0 value to 1 after a while(after about one minute). It does not wait until we explicitly set it to 1. So according to my experience this not a safe way to turn off binary logging at all.....!