I just upgraded a MySQL 5.0 server to MySQL 5.5 and found that stored routines that worked before had broken. Difference: MySQL 5.5 seems to INSERT rows in an arbitrary order. So in the following code the ORDER BY clause has no effect. AFAIK, it used to have that in MySQL 5.0.
INSERT INTO MyTable
SELECT * FROM MyOtherTable ORDER BY Col1, Col2 DESC;
People say that, by definition, order is irrelevant in INSERTs: Just use ORDER BY when using SELECT from the table. Problem is I use a cursor to loop the table and perform complex operations. Surely I can put the ORDER BY statement on the cursor definition instead:
DECLARE cur CURSOR FOR SELECT * FROM MyTable ORDER BY Col1, Col2 DESC;
But that slows down the routine: from 10 seconds on MySQL 5.0 to over 10 minutes on MySQL 5.5.
Any ideas on how to solve problem?
Add an index on (Col1, Col2) to speed up ordering.
Related
Does anyone know how to retrieve UUID via HSQLDB.
For example when i try
SELECT UUID();
via MYSQL it works fine. But the same statement doesn't work with HSQLDB.
The following methods achieve the corresponding purpose
VALUES (UUID())
CALL(UUID())
SELECT UUID() FROM (VALUES(0)) t;
Is there a way which is same for mysql and hsqldb?
HSQL doc says that UUID has been activated. http://hsqldb.org/doc/guide/builtinfunctions-chapt.html
Thanks.
Turn on the MySQL compatibility mode in HSQLDB and it will allow your SELECT statement:
http://hsqldb.org/doc/2.0/guide/compatibility-chapt.html#coc_compatibility_mysql
Is there a way which is same for mysql and hsqldb?
Only way i can think off.
Create a table DUAL in HSQLDB
CREATE TABLE DUAL (
id INT
);
So you can use
SELECT UUID() FROM DUAL LIMIT 1;
Then the query should work the same in both MySQL and HSQLDB.
DUAL in MySQL is a non existing dummy table.
In mysql, one can execute the following statement:
UPDATE trx SET lock_id=somevalue WHERE lock_id is NULL order by stamp desc limit 1
I'm looking for a statement or statements run in transaction that would accomplish the same thing and would work in both MySQL 5.7 and PostgreSQL 9.4
It is important for this to be atomic, as this statement is in MySQL.
I've a problem with MySql, here is the details :
I created a new schema/database, executed (only) this queries :
create table mytable (
id varchar(50) not null,
name varchar(50) null default '',
primary key (id));
create view myview as
select id,name from mytable;
insert into mytable values ('1','aaa');
insert into mytable values ('2','bbb');
insert into mytable values ('3','ccc');
and then, if I run these queries :
select * from mytable;
select * from myview;
prepare cmd from 'select id,name from mytable where id=?';
set #param1 = '2';
execute cmd using #param1;
the queries give the correct result (3 rows,3 rows,1 row).
but, the problem exists if I run this query:
prepare cmd from 'select id,name from myview where id=?';
set #param1 = '2';
execute cmd using #param1;
ERROR: #1615 - Prepared statement needs to be re-prepared
I've done some research and found that the increment of configurations below "may" solve the problem :
increase table_open_cache_instances value
increase table_open_cache value
increase table_definition_cache value
As far as I know, the queries above are the common and standard MySql queries, so I think there is no problem with the syntax.
I'm on a shared webhosting and using MySql version is 5.6.22
But the things that make me confused is, it only contain 1 schema/database, with 1 table with 3 short records and 1 view,
and I executed a common and standard MySql select query,
does the increment of values above really needed?
is there anyone with the same problem had increase the values and really solve the problem?
or, perhaps do you have any other solution which you think may or will works to solve this problem?
ps: it does not happen once or twice in a day (which assumed caused by some backup or related), but in all day (24 hours).
Thank you.
Do you do this after each execute?
deallocate prepare cmd;
The closest guess until now is some other shared members on the server dont write their code quite well (because it is a shared webhosting), either doing large alter while doing the large select, or dont deallocate the prepared statement after using it, like Rick James said. (want to make the post usefull, but I dont have the reputation, sorry Rick)
I can not make sure if the increment of "table_definition_cache" will works because the system administrator still wont change the value until now, but incase you having the same problem and you can modify it, it worth to try.
My current solution is I change all my views in my query strings into non-view or subqueries, it works for me, but the problem is still in the air.
eg. from
select myview.id, myview.name
from myview
inner join other_table on ...
where myview.id=?
into
select x.id, x.name
from (select id,name from mytable) x
inner join other_table on ...
where x.id=?
I am trying to fix this migration history problem but can't get this to work in MySQL
SELECT *
INTO [TempMigrationHistory]
FROM [__MigrationHistory]
DROP TABLE [__MigrationHistory]
EXEC sp_rename 'TempMigrationHistory', '__MigrationHistory'
How would I get this working in mySQL ?
A close equivalent mysql SQL for the SQL Server t-sql provided is something like what follows here. (Obviously field1, field2 are placeholders.)
CREATE TABLE `TempMigrationHistory` LIKE `__MigrationHistory`;
INSERT INTO `TempMigrationHistory` (field1, field2)
SELECT field1, field2
FROM `__MigrationHistory`;
DROP TABLE `__MigrationHistory`;
RENAME TABLE `TempMigrationHistory` to `__MigrationHistory`;
Points to note...
mysql does not support SELECT INTO but it does have the CREATE TABLE LIKE statement that SQL Server does not.
Backticks (`) are used by convention in mysql instead of square brackets ([) in t-sql.
mysql often has special system commands that take the place of SQL Server system stored procedure functionality (like sp_rename with RENAME TABLE in this case).
At the end of this sequence of operations it seems you have exactly what you started with so I'm a bit confused about the desire to execute this sequence of events, but I suppose that's a tangent to your question.
Not all RDBMS's behave the same. Have you considered searching for the MySQL syntax for creating an INSERT statement? E.g.,
INSERT INTO TempMigrationHistory
(Col1,
Col2,
Col3)
SELECT Col1,
Col2,
Col3
FROM __MigrationHistory
Also, sp_rename is a SQL Server Stored Procedure. An equivalent in MySQL is RENAME. In your case, this will probably work:
RENAME TABLE TempMigrationHistory TO __MigrationHistory;
I am trying to re-order a table after importing a file but am getting a mysql syntax error on this query:
ALTER TABLE tablename ORDER BY str_to_date(date, '%m/%d/%Y'), time_to_sec(time) ASC
Can anyone see anything wrong with this? this is the error I am getting:
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '(date, '%m/%d/%Y'), time_to_sec(time) ASC' at line 1
According to mysql manual, ALTER TABLE ORDER BY expects a col_name, but you are trying to order it using a function.
I suggest create 2 new columns, populate them with function results, and then order by them.
You might have to use a temp table for this since you're ordering by a function.
CREATE TABLE temp_tablename AS SELECT * FROM tablename;
TRUNCATE tablename;
INSERT INTO tablename SELECT * FROM temp_tablename;
DROP temp_tablename;
You could make the first statement a CREATE TEMPORARY TABLE, but if you lose your session you lose your data.
Did you try
ALTER TABLE tablename ORDER BY date, time ASC
I mention this because it might give you the order you need.
Otherwise you'll need to either do as German Rumm suggested, add columns with the correct datatype, or do your ordering when you do your SQL.
I think I resolved this issue. I was storing imported data in a temp table before moving it onto it's permanent table and needed to sort the data in the temp table first before inserting into the new table. so what I do instead is insert into the new table via a select statement which has the order by statement.
You are using an older version of mysql, STR_TO_DATE is only availabe from version 4.1.1 of MySQL.
Update MySQL version.