How can I remove multiple rows in one query in hypertable?
It seems that delete doesn't do so and I read something about compact command, but it seems that it's not implemented yet.
No, thats not yet implemented. You have to delete row by row. The COMPACT command does not have anything to do with that.
Related
Is it possible to "see" deleted rows in the same transaction before commit ?
I need to do this in a TRIGGER AFTER DELETE where I need to select the deleted rows which are deleted by a cascade constraint
update
It does not sound like its possible.. So I want to edit my question a bit.. Is it possible / is there a fast way to collect row ID's in a TRIGGER BEFORE DELETE and "send" them to a TRIGGER AFTER DELETE?
check this oracle docs if i understand clearly you need this..
http://docs.oracle.com/cd/B19306_01/backup.102/b14192/flashptr002.htm
Not sure what exactly your problem is, but maybe this info will help you.
In general I wouldn't recommend to grant delete permissions to anyone, accidental delete can have disastrous consequences. Instead of executing the delete rather mark the rows for deletion and just hide them on the front-end side. Then you can eventually delete them manually if necessary.
If you want to check what you are deleting before you do it you would have to prepare a script that instead of executing the DELETE prints the query first or shows the rows you are about to delete. Keep in might doing that might compromise your security. If you just want to see how much stuff you are about to delete you can SELECT COUNT first the items you want to delete and print something like: "you are about to permanently delete x items. Is that ok?"
If you need it for testing, to show you what was deleted etc., use MySQL Server Logs. They might be turned off by default, but it depends on your configuration (usually only error log is enabled by default). Then you could check the General Query Log but it only logs executed queries, so you will only see that someone executed DELETE FROM x WHERE y=z but you won't see the values that actually got deleted, only the executed query. Also keep in mind that general query log can grow really fast depending on your workflow, on the other hand gives you a great insight of what was the last thing a particular user did before he encountered an error etc.
Does any of this helps you? If you need more info on particular topic post a comment and I will edit accordingly.
We have to automate a lot of queries and the problem is, in some of them we have to first handle some base cases. And, we still want to automate a lot of work. So, is it possible to add triggers after entries have been done?
I am using MySQL as database. I need to update some data. However the data may haven't changed so I may not need to update the row in such case.
I wanted to know which one will be better (performance wise):
a) Search the table to determine if the data has changed. For example I can search by primary key and then see if the value of remaining fields have changed or not. If yes, then continue with update statement and if not then leave it.
b) Use UPDATE query directly. If there are no changes in the data, MySQL will automatically ignore it and not process updating the data.
So which one will be perform better in such case.
From the MySQL manual:
If you set a column to the value it currently has, MySQL notices this
and does not update it.
So save yourself the latency and leave that task to MySQL. It will even tell you how many rows were actually affected.
First options seems better to me but in a specific scenerio.
Select all or some rows from table and get them in a result set
Traverse the result set, as in-memory traversal is really fast enough, and pick up the primary keys whose records you want to update and then execute update queries.
It seems comparetively efficient solution to me as compared to executing update query on each row regardless whether you need to do so or not.
If you use the select-then-update approach, you need to lock the row (e.g. select for update), otherwise you are in a race condition - the row can be changed after you selected and checked that it hasn't be changed.
As #AndreKR pointed out, MySQL won't perform any write operation, if the values are the same, so using update directly is faster than using 2 queries.
Is it possible to log all queries that are executed? I am looking at a database that is accessed by many different apps. One of them is modifying a table's value in a way it should not. I am trying figure out which app is the culprit. It would help me out a lot if I can capture all the queries that are executed on that table and at what time.
Many thanks in advance for your help.
Either use the --log[=file_name] command line switch on mysqld or edit/create a my.cnf containing:
[mysqld]
log=/tmp/mysql.log
Explained fully in this article.
As far as I am aware, there are currently no auditing capabilities built in to MySQL. Log queries from within the applications that generate them, or sniff connections to the server.
in your .ini configuration add this line
log=allqueries.log
you will need to restart mysql
A possible solution to your problem is to utilize an update trigger on the table in question. The trigger will be fired on any update to the table, and it possible to write the trigger such that when it meets certain criteria (the value in question is changed), an action is performed (perhaps writing to a temporary table, the SQL statement that makes the change). For more information, I suggest looking at Trigger Syntax.
Take a look here: http://dev.mysql.com/doc/refman/5.1/en/server-logs.html
You're looking for general query log: http://dev.mysql.com/doc/refman/5.1/en/query-log.html
You can use the general log in MySQL to achieve this. I only recommend you do that on a test/development database without many concurrent users, because the amount of output generated is huge. I'm not sure if it logs the timestamp, though.
If it doesn't, on a unix/linux setup, I'd say write a simple script that read lines from the stdin and print the lines with the current timestamp when they were read, and pipe tail -f on the log file to it, so you can add your own timestamps.
is there a way to preview a mysql queries results before processing?
If you're asking whether it's possible to execute MySQL commands, look at the results and decide whether you actually want these changes, look at transactions.
http://dev.mysql.com/doc/refman/5.0/en/commit.html
I've never done it but my guess would be you could create a temporary table from the table in question and run the query on that table. Hopefully this gets you going in the right direction.
It depends on what you want to achieve, if you want to know what mysql will do with your query you might be interessted in
http://dev.mysql.com/doc/refman/5.0/en/explain.html
Turn autocommit off, run your query and then rollback. It's universal and I know of no other way that's as simple as this.