Running a fairly old version of MySQL:
mysql> SELECT ##version;
+-----------+
| ##version |
+-----------+
| 5.0.77 |
+-----------+
Afraid I'm not at liberty to update it, so I acknowledge the easy answer may be "Upgrade MySQL to a newer version."
When I do SELECT...INTO query which should return a single row with only one column I get an error:
mysql> SELECT id
INTO #active_id
FROM a_table
WHERE active = 1
LIMIT 1
;
> Undeclared variable: id
But if I add an additional column, it works fine:
mysql> SELECT id, 42
INTO #active_id, #ignored
FROM a_table
WHERE active = 1
LIMIT 1
;
> Query OK, 1 row affected (0.00 sec)
mysql> SELECT #active_id, #ignored;
+------------+----------+
| #active_id | #ignored |
+------------+----------+
| 1 | 42 |
+------------+----------+
Is there a better workaround for this? Is my syntax wrong somehow?
Related
I need to lock and perform two select statements on two MySQL/InnoDB tables. Both tables have related row name updateId.
SELECT ..., updateId FROM Table1 WHERE ...
SELECT ..., updateId FROM Table2 WHERE ...
I need to prevent updates, inserts or deletions (any modifications on the tables) until both SELECT statements execute.
Basically I want to prevent any changes to updateId row between the two statements.
I was looking at SELECT ... FOR SHARE and SELECT ... FOR UPDATE but I'm just a bit unclear how it works.
The other process can!! write, but the first process works wit the data at the moment from the transaction.
here is a sample with transaction
MariaDB [trans]> select * from table1;
+----+-------------+
| id | field1 |
+----+-------------+
| 1 | table 1 -1 |
| 2 | table 1 - 2 |
+----+-------------+
2 rows in set (0.001 sec)
MariaDB [trans]> start transaction;
Query OK, 0 rows affected (0.000 sec)
MariaDB [trans]> select * from table1;
+----+-------------+
| id | field1 |
+----+-------------+
| 1 | table 1 -1 |
| 2 | table 1 - 2 |
+----+-------------+
2 rows in set (0.000 sec)
CLIENT 2:
MariaDB [trans]> update table1 set field1 = 'new value' where id = 1;
Query OK, 1 row affected (0.003 sec)
Rows matched: 1 Changed: 1 Warnings: 0
MariaDB [trans]>
MariaDB [trans]> select * from table1;
+----+-------------+
| id | field1 |
+----+-------------+
| 1 | table 1 -1 |
| 2 | table 1 - 2 |
+----+-------------+
2 rows in set (0.001 sec)
MariaDB [trans]> commit;
Query OK, 0 rows affected (0.001 sec)
MariaDB [trans]> select * from table1;
+----+-------------+
| id | field1 |
+----+-------------+
| 1 | new value |
| 2 | table 1 - 2 |
+----+-------------+
2 rows in set (0.001 sec)
MariaDB [trans]>
START TRANSACTION;
SELECT ... FOR UPDATE;
SELECT ... FOR UPDATE;
blah, blah, blah
UPDATE/INSERT/etc (if desired)
COMMIT;
FOR UPDATE means "I might change the rows in this SELECT, so keep your hands off!"
I'm testing the InfiniDB community edition to see if it suits our needing.
I imported in a single table about 10 millions rows (loading of data was surprisingly fast), and I'm trying to do some query on it, but these are the results (with NON cached queries.. if query caching exists in InfiniDB):
Query 1 (very fast):
select * from mytable limit 150000,1000
1000 rows in set (0.04 sec)
Query 2 (immediate):
select count(*) from mytable;
+----------+
| count(*) |
+----------+
| 9429378 |
+----------+
1 row in set (0.00 sec)
Ok it seems to be amazingly fast.. but:
Query 3:
select count(title) from mytable;
.. still going after several minutes
Query 4:
select id from mytable where id like '%ABCD%';
+------------+
| id |
+------------+
| ABCD |
+------------+
1 row in set (11 min 17.30 sec)
I must be doing something wrong, it's not possible that it's performing this way with so simple queries. Any Idea?
That shouldn't be the case, there does appear to be something odd going on, see quick test below.
What is your server configuration: memory/OS/CPU and platform (dedicated, virtual, cloud).
Could I get the schema declaration and method to load the data?
Which version are you using? Version 4 community has significantly more features than prior versions, i.e. core syntax matches enterprise.
Cheers,
Jim T
mysql> insert into mytable select a, a from (select hex(rand() * 100000) a from lineitem limit 10000000) b;
Query OK, 10000000 rows affected (1 min 54.12 sec)
Records: 10000000 Duplicates: 0 Warnings: 0
mysql> desc mytable;
+-------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------+-------------+------+-----+---------+-------+
| id | varchar(32) | YES | | NULL | |
| title | varchar(32) | YES | | NULL | |
+-------+-------------+------+-----+---------+-------+
2 rows in set (0.01 sec)
mysql> select * from mytable limit 150000,1000;
+-------+-------+
| id | title |
+-------+-------+
| E81 | E81 |
| 746A | 746A |
. . .
| DFC8 | DFC8 |
| 2C56 | 2C56 |
+-------+-------+
1000 rows in set (0.07 sec)
mysql> select count(*) from mytable;
+----------+
| count(*) |
+----------+
| 10000000 |
+----------+
1 row in set (0.06 sec)
mysql> select count(title) from mytable;
+--------------+
| count(title) |
+--------------+
| 10000000 |
+--------------+
1 row in set (0.09 sec)
mysql> select id from mytable where id like '%ABCD%' limit 1;
+------+
| id |
+------+
| ABCD |
+------+
1 row in set (0.03 sec)
Is it possible to configure MySQL to return TIMESTAMP value as a UNIXTIMESTAMP by default, rather than casting every column in the SELECT statement?
MySQL has a function to convert a date to a unix timestamp.
https://dev.mysql.com/doc/refman/5.5/en/date-and-time-functions.html#function_unix-timestamp
mysql> SELECT UNIX_TIMESTAMP();
-> 1196440210
mysql> SELECT UNIX_TIMESTAMP('2007-11-30 10:30:19');
-> 1196440219
You cannot do that in MySQL configuration.
You can do that on application level - e.g. in PHP, you can use the mysqli_result::fetch_fields() method to detect timestamp type and convert it, other connectors will have similar methods.
Or you can do it - as suggested - using UNIX_TIMESTAMP() function on timestamp columns.
It sounds as though you want a different view of the same data:
mysql> select * from t;
+------+---------------------+
| data | ts |
+------+---------------------+
| foo | 2013-03-19 16:54:45 |
+------+---------------------+
1 row in set (0.00 sec)
mysql> select data, unix_timestamp(ts) from t;
+------+--------------------+
| data | unix_timestamp(ts) |
+------+--------------------+
| foo | 1363712085 |
+------+--------------------+
1 row in set (0.00 sec)
mysql> create view tv (data, time_t) as select data, unix_timestamp(ts) from t;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from tv;
+------+------------+
| data | time_t |
+------+------------+
| foo | 1363712085 |
+------+------------+
1 row in set (0.00 sec)
I have one query I am using following query to select record from MySQL
mysql> select VID from tm_visitor where DATE(INTIME)=DATE('2012-08-01');
then I am getting result as
+--------+
| VID |
+--------+
| 000001 |
| 000002 |
| 000003 |
| 000004 |
+--------+
4 rows in set (0.00 sec)
But when I use query as
mysql> select VID from tm_visitor where DATE(INTIME)=DATE('01-AUG-2012');
it gives me nothing
Empty set, 8 warnings (0.00 sec)
How to solve this?
try this
select VID from tm_visitor where DATE(INTIME) = STR_TO_DATE('01-AUG-2012', '%d-%b-%y')
See MySQL Reference for more examples
In the following example, why does the min() query return results, but the max() query does not?
mysql> create table t(id int, a int);
Query OK, 0 rows affected (0.10 sec)
mysql> insert into t(id, a) values(1, 1);
Query OK, 1 row affected (0.03 sec)
mysql> insert into t(id, a) values(1, 2);
Query OK, 1 row affected (0.02 sec)
mysql> select * from t
-> ;
+------+------+
| id | a |
+------+------+
| 1 | 1 |
| 1 | 2 |
+------+------+
2 rows in set (0.00 sec)
mysql> select * from t where a < 4;
+------+------+
| id | a |
+------+------+
| 1 | 1 |
| 1 | 2 |
+------+------+
2 rows in set (0.00 sec)
mysql> select * from t where a < 4 having a = max(a);
Empty set (0.00 sec)
mysql> select * from t where a < 4 having a = min(a);
+------+------+
| id | a |
+------+------+
| 1 | 1 |
+------+------+
1 row in set (0.00 sec)
The HAVING clause is used to filter groups of rows. You reference min(a) and max(a) which (in the absence of any GROUP BY clause) aggregate over all a values in the table but then use a comparison against a single a value.
So which a value is MySQL supposed to use? All other RDBMSs that I know of would throw an error at this point however MySQL does allow this. From the docs
Standard SQL does not permit the HAVING clause to name any column
not found in the GROUP BY clause unless it is enclosed in an aggregate
function. MySQL permits the use of such columns to simplify
calculations. This extension assumes that the nongrouped columns will
have the same group-wise values. Otherwise, the result is
indeterminate.
So in your case from the results you are getting it appears that it ended up using 1 as the scalar value for a but this behaviour is not guaranteed and it could equally well have used 2 or any other existing a value.