Mysql temp tables are dropped between executions - mysql

I want be able to debug easily my scripts in Mysql, like in MSSQL (run a chunk of the script then verify the tables and so on), but the temporary tables are not persisted on the server.
For example :
CREATE temporary table a(i int);
INSERT INTO a VALUE (1);
SELECT * FROM a;
If I run the whole script it returns me the right result, but if I run it statement by statement on the insert I get the following error:
SQL.sql: Error (2,13): Table 'test.a' doesn't exist
I suppose this is a server configuration problem.

Temporary tables are dropped when the transaction is over.
from dev.mysql:
Temporary Tables:
You can use the TEMPORARY keyword when creating a
table. A TEMPORARY table is visible only to the current connection,
and is dropped automatically when the connection is closed. This means
that two different connections can use the same temporary table name
without conflicting with each other or with an existing non-TEMPORARY
table of the same name. (The existing table is hidden until the
temporary table is dropped.) To create temporary tables, you must have
the CREATE TEMPORARY TABLES privilege.
Note CREATE TABLE does not automatically commit the current active
transaction if you use the TEMPORARY keyword.
So if you run all these sql in deferent transactions you temporary table wont exist when you run the insert statement.
If these executions are executed in diferent transactions depend on what interface you use. Thats wy if you "run the whole script it returns me the right result" because its all in the same transaction.
You can try to force it to run on the same transaction with:
START TRANSACTION;
<SQL QUERYS>
COMMIT;
anyway i recomend you MySQL Workbench as interface.
my best regards, i hope this help you.

Related

Aurora MySQL - Slow CREATE TABLE statement in Stored Proc

We have been struggling with slow (never finishing) running stored procedures. We have been focusing on a particular CREATE TABLE ... SELECT ... from table with some joins.
When we run this query on it's own it completes consistently in about 14 seconds. When it is run as part of the Stored Proc it wont complete even after hours.
What we found if we take all the code in the stored proc and just run it as a normal SQL script then it is also slow. Further up in the stored proc tables are created from base data and prepared to be used by the Stored Proc.
We are running 5.7.mysql_aurora.2.07.2 and tested on 5.7.mysql_aurora.2.07.1 as well. I suspect we need to tune some database settings but I lack the experience in InnoDB and Aurora.
We migrated from MyISAM into Aurora where we now use InnoDB and any any guidance on what could be the cause of this would be much appreciated.
EDIT:
I did try to change the statements from CREATE TABLE ... SELECT ... from table to a CREATE TABLE followed by INSERT INTO which made no difference.
What seems to have worked is to use
create table A (PRIMARY KEY (name)) select ... for all tables created instead of first creating the table and using an ALTER statement to add the key.
I am stumped as to why this mode it work???
This sounds like a table locking issue. Typically
CREATE TABLE AS SELECT ... FROM table_name ...
results in the source table (table_name) needing locking.
Try breaking apart the CREATE and the SELECT, i.e.
CREATE TABLE table_name ...;
INSERT INTO table_name SELECT ...;

How to rename two tables in one atomic operation in MySQL

I need to rename two tables in one atomic operation so that user will never be able to see the database in its intermediate state.
I'm using MySQL and noticed that this case is perfectly described in the documentation:
13.3.3 Statements That Cause an Implicit Commit
The statements listed in this section (and any synonyms for them)
implicitly end any transaction active in the current session, as if
you had done a COMMIT before executing the statement
[...]
Data definition language (DDL) statements that define or modify
database objects. ALTER DATABASE ... UPGRADE DATA DIRECTORY NAME,
ALTER EVENT, ALTER PROCEDURE, ALTER SERVER, ALTER TABLE, ALTER VIEW,
CREATE DATABASE, CREATE EVENT, CREATE INDEX, CREATE PROCEDURE, CREATE
SERVER, CREATE TABLE, CREATE TRIGGER, CREATE VIEW, DROP DATABASE, DROP
EVENT, DROP INDEX, DROP PROCEDURE, DROP SERVER, DROP TABLE, DROP
TRIGGER, DROP VIEW, INSTALL PLUGIN (as of MySQL 5.7.6), RENAME TABLE,
TRUNCATE TABLE, UNINSTALL PLUGIN (as of MySQL 5.7.6).
But maybe there's some kind of workaround or something like this?
My situation looks like this:
I have a current data set in the table named current
I gathered a new data set in the table named next
I need to rename the current table to the current_%current_date_time% and the next table to the current in one atomic operation
Well, easy...
RENAME TABLE current TO current_20151221, next TO current;
as is stated in the manual. There it says that it's an atomic operation. Just to clear this up, implicit commits have nothing to do with it. That's a different story. That just says, that those statements end an open transaction.

Drop table, then cannot recreate table with the same name

I first drop a table in SQL Server 2008 (after that it shows the message that the command was executed sucessfully).
I then tried to create a table with the same name, and it showed me an error.
After closing the SSMS window and re opening it it tried to create the table with the same name again and it succeeded.
What is going on?
You can't drop and create the same table in the same batch in sql server
see MSDN
Their examples use GO to break up the two commands. Semi colon might work,
Drop Table ...;
Create Table ,,,;
as might
Begin Transaction
Drop Table...
Commit Transaction
Create Table
Or of course splitting it up into two commands, which is what GO does in SQL server manager's query window.
If you do split it up, it might be wise to check whether the table exists before trying to drop it, and that it doesn't before trying to create it.

No data if queries are sent between TRUNCATE and SELECT INTO. Using MySQL innoDB

Using a MySQL DB, I am having trouble with a stored procedure and event timer that I created.
I made an empty table that gets populated with data from another via SELECT INTO.
Prior to populating, I TRUNCATE the current data. It's used to track only log entries that occur within 2 months from the current date.
This turns a 350k+ log table into about 750 which really speeds up reporting queries.
The problem is that if a client sends a query precisely between the TRUNCATE statement and the SELECT INTO statement (which has a high probability considering the EVENT is set to run every 1 minute), the query returns no rows...
I have looked into locking a read on the table while this PROCEDURE is ran, but locks are not allowed in STORED PROCEDURES.
Can anyone come up with a workaround that (preferably) doesn't require a remodel?
I really need to be pointed in the right direction here.
Thanks,
Max
I'd suggest an alternate approach instead of truncating the table, and then selecting into it...
You can instead select your new data set into a new table. Next, using a single RENAME command, rename the new table to the existing table and the existing table to some backup name.
RENAME TABLE existing_table TO backup_table, new_table TO existing_table;
This is a single, atomic operation... so it wouldn't be possible for the client to read from the data after it is emptied but before it is re-populated.
Alternately, you could change your TRUNCATE to a DELETE FROM, and then wrap this in a transaction along with the SELECT INTO:
START TRANSACTION
DELETE FROM YourTable;
SELECT INTO YourTable...;
COMMIT

Is MySQL Temporary table a shared resource?

I have a MySQL stored procedure that uses a temporary table. Assume that my table name is 'temp' and I use it to store some middle data. It will create at the beginning of procedure, and will drop at the end.
CREATE PROCEDURE p()
BEGIN
CREATE TEMPORARY TABLE \`temp\`(...);
INSERT INTO \`temp\` VALUES(...);
DROP TEMPORARY TABLE \`temp\`;
END;
The problem is that this stored procedure may be used by different users concurrently, so I want to know if this can cause any problems (i.e. any conflict in inserted data in temp table). In other word is temp table a shared resource within different calls to the same SP?
No, a temp table is limited to the scope of your database connection. You can use the temp table in subsequent calls to the procedure during the same database connection, but other connections cannot access it. They can create a table by the same name, but each temp table will be independent. Temp tables go away when you close your connection.
Temporary table is visible only for current session.
So if you have several simultaneuous sessions - each one will have its own independent temporary table with the same name.
Documentation: http://dev.mysql.com/doc/refman/5.1/en/create-table.html, ctrl+f for "You can use the TEMPORARY"