MySQL: NULL, 0, or -1 as the Default Value?

This time instead of a tutorial, some reflections.

Situation description: Two tables: agent and operations. The operations table has a foreign key defined on the agentID field pointing to the agent table.
Problem: A default value needs to be created for the agentID field.

To make the problem less straightforward, let's assume that each table has 100,000 records and that this data is used in some application (e.g. PHP). This makes the question of indexing and sorting relevant.

NULL as the default value.

By default, in the described situation, using NULL is the suggested approach. In this case, when creating a new record in the operations table, the key will not be looked up in the agent table.

On one hand, NULL is "nothing" and one might assume it is not indexed. However, executing the query:

EXPLAIN SELECT * FROM operations WHERE agentID IS NULL

we can see that indices are in fact used.

The next consideration is handling NULL values in the application (in our case PHP). Specifically, when selecting NULL values they may be displayed as empty, as the text "(null)" or given some semantic meaning, e.g. [agent not specified]. In PHP, NULL will be shown as an empty value and at best will trigger a Notice. In "stricter" languages like Java, an exception will be thrown.
Everything is fine as long as such semantic explanations of NULL values need to be provided in one language only.

0 as the default value.

In this case, it is a value, and a record with exactly that key must exist in the agents table for it to be usable in the operations table as well. The benefit - this way a default record could be obtained, which would resolve the question of what to do when the default value needs to be in different languages.
There is also a problem. When creating a new record and specifying 0 for the id field (id field - int, auto_increment), the auto_increment condition automatically takes effect - meaning the field's value no longer stays 0 but instead gets the assigned auto_increment value.
One thing is clear: on INSERT, even if you use id value 0, the record won't be modified (a new record will be created instead), while backup/restore will also behave incorrectly, for the same reason.

1 or -1 as the default value.

Three good things. The first record in the agents table is taken as the default value - so 1. If the id value is "signed", then -1 is also possible.
-1 looks more visually pleasant and won't cause confusion when visually inspecting data. Both 1 and -1 are values, so there is no doubt about indexing efficiency.

There is some confusion about the negative value, however. Firstly, I have never read or seen anywhere that negative numbers are used as id values. Secondly, when writing a negative number in binary, the most significant bit (sign bit) changes to 1, yielding 1000....000010101. And here I start wondering what effect that might have on indexing with an insanely large data volume.

Reading material on NULL:
- NULL, indices, surrogate values and other beasts
- MySQL lesson learned