Let me address each of your three Questions
QUESTION #1
Are the tables of all databases in the server locked during the mysqldump?
ANSWER TO QUESTION #1
Depends on the default settings you allow and what setting you use to override. The --opt parameter is enabled by default. That enables --add-drop-table, --add-locks, --create-options, --quick, --extended-insert, --lock-tables, --set-charset, and --disable-keys.
If you have a database with all InnoDB tables or a mix of InnoDB tables and read-only MyISAM tables, you can just use --single-transaction. This will create a clean point-in-time snapshot of all tables involved in the mysqldump. Any INSERT/UPDATE/DELETE queries against an InnoDB table will not interfere with the point-in-time consistency of the mysqldump.
By the way, --single-transaction is mutually exclusive to --lock-all-tables. Thus, using --single-transaction will disable --lock-all-tables.
QUESTION #2
If I have to do an incremental backup using mysqlbinlog from the last full backup, should I take the time when mysqldump started or when it ended?
ANSWER TO QUESTION #2
You could take the time if you do mysqlbinlog at different times of the day. You could save yourself some off that housekeeping information by simply running FLUSH LOGS; or FLUSH BINARY LOGS; the same time every night. For example, you could script a cronjob to run FLUSH LOGS;at 11:59 PM like this
#!/bin/sh
sleep 55
mysql -uroot -p... -e"FLUSH LOGS;"
That way you can logically group together all binary logs that have the same date when formulating any needed incremental backup.
You do not have record times or positions in this respect: If you include the option --master-data=2 in the mysqldump, the log file and position at recorded as a comment on line 22 of the mysqldump output.
QUESTION #3
What happens when one is using the database when mysqldump is running? How can I take the start time for mysqlbinlog? What happens when mysqldump is executed?
ANSWER TO QUESTION #3
Here is where you have to be very careful. As I mentioned earlier, if you have a database with all InnoDB tables or a mix of InnoDB tables and read-only MyISAM tables, you can use --single-transaction and every table involved in the mysqldump will exist in the same point-in-time.
What Can Go Wrong #1
If you are performing INSERT/UPDATE/DELETE queries against a MyISAM table during the mysqldump, then the MyISAM tables will not be point-in-time consistent.
What Can Go Wrong #2
If you are performing ALTER TABLE, DROP TABLE, RENAME TABLE, or TRUNCATE TABLE against any table (MyISAM or InnoDB), consistent mysqldumps are no longer isolated. The transaction you issued with --single-transaction is released (made null and void) and all tables afterward can no longer the point-in-time consistent.
If one of these occur, recording start times or position is rendered useless.
You need to add the LIMIT clause
SELECT id FROM tbl_play WHERE id = 1 OR gameid = 0 LIMIT 1;
This is an oversimplified answer.
If there is a row with PK=1, you find it.
If not, a full table scan may ensue because of gameid not being indexed.
You are better off splitting the query with a UNION. Perhaps, like this:
SELECT id FROM
(
SELECT id FROM tbl_play WHERE id = 1
UNION
(SELECT id FROM tbl_play WHERE gameid = 0 LIMIT 1)
) A ORDER BY id LIMIT 1;
Since I do not know the data, I cannot predict any performance results.
Give it a Try !!!
UPDATE 2014-01-23 11:01 EST
The reason it works because of the goal I set for the query : Retrieve one value.
First look at the UNION
SELECT id FROM tbl_play WHERE id = 1
UNION
(SELECT id FROM tbl_play WHERE gameid = 0 LIMIT 1)
The first SELECT can return at most one row.
The second SELECT can return at most one row because of the LIMIT 1.
In the worst case scenario, the UNION will have two rows.
Now look at the whole query:
SELECT id FROM
(
SELECT id FROM tbl_play WHERE id = 1
UNION
(SELECT id FROM tbl_play WHERE gameid = 0 LIMIT 1)
) A ORDER BY id LIMIT 1;
The outer part of the query will receive either 0, 1, or 2 rows.
Then, the part ORDER BY id LIMIT 1 forces the outer query to choose the first value.
Best Answer
The rules I would have applied to determine the validity of the scenarios seems pretty straightforward:
When a clock-in occurs between the start and end times of "any" assigned shift, that's a late clock-in for the shift with the start and end times that the clock-in occurs "between" (scenario 1)...
Conversely, when the clock-in is prior to the start time of an assigned shift but also after the end time of another shift (or, to state this another way, it occurs "not between" the start and end of any other assigned shift), that's an early clock-in (scenario 2) for the next shift to start after the clock-in event.
It seems that both pieces can be combined together:
(pseudocode)
SELECT sch.start_time, sch.stop_time from employee JOIN employee_schedule JOIN schedule sch WHERE sch.stop_time > clock_in_time ORDER BY stop_time LIMIT 1;
I would suggest that this query should always return the schedule to which the clock-in timestamp applies. It's "the first shift that ended after you clocked in."
If the start_time of the shift is earlier than the clock_in_time, then you're late... if it's later than the clock_in_time, then you're early.