We have lots of database in one instance.
Our query language is:
use db1; select * from table1;
use db2; select * from table2;
But when we change to this style, the MySQL server CPU load dropped a lot:
select * from db1.table1;
select * from db2.table2;
What's the different between them?
Which one should we use?
MySQL can work with multiple databases in a single query. Each table belongs to a single database. Its full name is: database.table.
If you are sticking to a single database, then you probably don’t want to work with the database prefix. USE database allows you to dispense with the prefix.
If you are using multiple databases simultaneously, then you’re never going to be in the right database. At the very lease, you will need to prefix the other database tables.
I don’t know how much work MySQL does when you apply the USE database statement, but I imagine that it’s not very important in the overall scheme of things. Under normal circumstances you are working with a single database so issuing the USE statement once should be the end of it.
Certainly if you’re constantly switching between the two, and especially if you’re joining tables from different databases, then you should prefix the tables.
Related
I'm developping a web platform to manage student registrations in schools of my region. For that I have 17 databases running on MySQL (5.7.19) where there is one which is the main database and the 16 others represent schools. Schools databases (must) have the exactly the same schema, each containing data corresponding to the associated school. I separated this way to avoid latency as each school can register many applications (16k on average), so the requests could get heavier over time.
Now I have a serious problem: when I change the schema of a school's database, I have to manually do it for those of other schools to keep the schema consistency because my sql requests are made independently of the school. For example, if i add a new field in table_b of database_school5, i have to manually do the same on table_b of all remaining databases.
What can I do to manage theses changes efficiently? Is there an automatic solution? Is there an adapted DBMS for this problem?
Somebody told me that PostgreSQL can achieve this easily with INHERITANCE, but this only concerns the tables, unless I've done some poor research.
I want every time I make a change to a database schema, whether it is adding a table, adding a field, removing a field, adding a constraint, etc., the changes are automatically transferred to the other databases.
Thanks in advance.
SELECT ... FROM information_schema.tables
WHERE schema_name LIKE 'database_school%'
AND table_name != 'the 17th table'
AND schema_name != 'database_school5' -- since they have already done it.
That will find the 16 names. What you put into ... is a CONCAT(...) to construct the ALTER TABLE ... statements.
Then you do one of these:
Plan A: Manually copy/paste those ALTERs into mysql commandline tool to perform them.
Plan B: Wrap all of it in a Stored Procedure that will loop through the results of the SELECT and prepare+execute each one.
Correct me if I'm wrong, but my understanding is that, in MSSQL, sub-structures of a database like Views, Schemas and Tables can be referenced using object notation such as:
Database.Schema.Table.Column
Each of these objects I believe has their own properties.
I need to replicate the structure of an MSSQL DB in MySQL and I am unsure what is the best practice.
I am thinking about creating tables in MySQL with the following naming convention:
Database
|---SubStructureX.Table
| |---Column_A
| |---Column_B
|---SubStructureY.Table
| |---Column_C
| |---Column_D
|
|
Therefore a MySQL query could look like this:
SELECT Column_A, Column_B FROM SubStructureX.Table
In short, "SubstructureX.Table" is just a table name that contains a dot. I would be doing this for ease of use during replication of the MSSQL structure. I don't care if the things before and after the dot are not objects in MySQL.
Is this good MySQL practice?
In MySQL? No, I would think that it's not good practice to use periods in table names at all. I would think that it's very bad practice. The dot is the reference operator in SQL. That means if you want to refer to a column using fully qualified notation, you do so like this:
SELECT Table.Column_A ...
Or, with backtick quoting:
SELECT `Table`.`Column_A` ...
Now, imagine if your table is named StructureX.Table. Just like with a space, you've got to quote that to escape it because you don't want MySQL to think the dot is an operator. That means your SQL has to look like this:
SELECT `StructureX.Table`.Column_A ...
Or, with backtick quoting:
SELECT `StructureX.Table`.`Column_A` ...
Doesn't that look like a syntax error to you? Like maybe it's supposed to be like this:
SELECT `StructureX`.`Table`.`Column_A` ...
This would be a nightmare to maintain and as a systems analyst I would hate any application or developer that inflicted this nomenclature on me. It makes me want to claw my eyes out.
Microsoft SQL Server is different because it supports multiple schemas within a single database, while MySQL treats schema as a synonym for database. In MS SQL Server, schemas are collections of objects, and you can use them to organize your tables, or apply security to tables as a group. The default schema is dbo, which is why you see that one listed so often. In MS SQL Server syntax, this:
SELECT [StructureX].[Table].[Column_A] ...
Means within the current database, the schema named StructureX, table named Table, and column name Column_A. MS SQL Server actually supports a four part name, with the fourth part being the database:
SELECT [MyDatabase].[StructureX].[Table].[Column_A] ...
Here, MyDatabase is the database name.
That same style works in MySQL, except you have to remember that schema and database are synonymous. So there, this:
SELECT `StructureX`.`Table`.`Column_A` ...
Would mean database StructureX, table Table, and column Column_A.
I Can say yes:
But instead of using table name, make a table some alias like this,
select a.column1 from yourTable as a
Using table alias is a good practice.
I've learned how to do simple search and replace operations in my MySQL databases using phpMyAdmin...
UPDATE my_table SET my_column = replace(my_column,'Spain','Spanish')
I just wondered if there are ways to target more than one fields and/or tables at a time. For example, if you have three tables named One, Two and Three and each one has a field named Article, could you do a search-and-replace operation in all three tables simultaneously? Or could you even search fields with different names, like One.Article, Two.Article, Three.Content?
Solutions don't have to be limited to phpMyAdmin. I'm interested in learning about other popular DB administration programs.
Yes, UPDATE supports multi-table syntax:
UPDATE One, Two, Three
SET One.Article = replace(One.Article,'Spain','Spanish'),
Two.Article=replace(Two.Article,'Spain','Spanish'),
Three.Content=replace(Three.Content,'Spain','Spanish');
I've been asked to build a module for a web application, which will also be used as a stand alone website. Since this is the case, I wanted to use a separate database, and wondered if there was a way of having a table in one database, be a "pointer" in another database.
For example, I have databases db1 and db2
db1 has table users, so I want to have db2.users point to db1.users.
I know I could setup triggers and what not to sync two seperate tables but this sounds cooler :)
EDIT
So in my code I'm using sql such as
select * from users
Now, at the database level, I want "users" to actually be db1.users. Then, if I want to, I can remove the alias/pointer and "select * from users" will point to the users table in the current database. I guess what I'm looking for is a "global alias" type of thing.
Just use it directly from another database?
SELECT ... FROM `db1`.`users` LEFT JOIN `db2`.`something`
The federated storage engine offers something similar to the feature you asked for.
And if your databases are on the same database server, the federated storage enging sounds a bit like an overkill to me. You may want to create a view instead.
Both methods won't be useful if db1 is not available. As Emmerman already points out, you need to store the data in db2 if you want to prepare for the case of db1 being unavailable.
What is the best thing to approach something like:
select * from (show tables like "T_DATA___") // Invalid
There are over 600 tables with the name T_DATAxy where x and y are letters
Something went seriously wrong with this design. Accessing 600 tables at once means accessing as much as 1800 files on disk. You should've partitioned this data instead.
As far as th question goes, Im afraid that you will need to use a stored procedure or external application, to build a multiple UNION query statement. Still, I seem to remember that there's a limit of 32 tables merged in a UNION.
You could get the list of tables whose data you want (show tables like __) and then use mysql dump, passing in that list.
http://dev.mysql.com/doc/refman/5.1/en/mysqldump.html
If you are determined to get it from SQL queries, you could generate appropriate sql queries using macros and execute them all at once. e.g. get the list of tables, replace newline with "; (newline) select * from ", execute all queries. (The emacs mysql mode makes this super easy).
As the other commenter says, you won't be able to do it in a single query due to #-table limits.