För att utöka något om vad Andre sa:
Eftersom ObjectID-tidsstämpeln endast är till den andra, kan två (eller fler) ObjectIDs enkelt skapas med samma värde för tidsstämpeln (de första 4 byten). Om dessa skapades på samma maskin (maskin-ID - nästa 3 byte), med samma process (PID - nästa 2 byte), skulle det enda som skulle skilja dem vara "inc"-fältet, de sista 3 byte på slutet.
Uppdatering:januari 2020
Det här svaret fortsätter att vara populärt så det är värt att uppdatera lite. ObjectID-specifikationen har utvecklats sedan det här svaret skrevs för 8 år sedan och de 5 byten efter tidsstämpeln är nu helt enkelt slumpmässiga, vilket avsevärt kommer att minska sannolikheten för eventuella kollisioner. De sista tre byten är fortfarande inkrementella, men initieras med ett slumpmässigt värde för att starta, vilket återigen gör kollisioner mindre sannolika. Objekt-ID:t innehåller nu mindre kontext (du kan inte enkelt avgöra var det genererades och genom vilken process) men jag skulle gissa att informationen inte användes på något meningsfullt sätt och har förkastats till förmån för bättre randomisering av ID:t.
Avsluta uppdatering
Se här för hela specifikationen:
https://docs.mongodb.com/manual/reference/method/ObjectId/#ObjectIDs-BSONObjectIDSpecification
Det "inc"-fältet är antingen ett ständigt ökande fält (då kan du rimligen förvänta dig att sorteringen ska vara i infogning/skapa-ordningen) eller ett slumpmässigt värde (då sannolikt unikt, men inte ordnat), förutsatt att specifikationen är korrekt implementerad förstås . Observera att ObjectID:n kan genereras av drivrutinen, eller applikationen (eller faktiskt manuellt) snarare än av MongoDB själv, så om du inte har full kontroll över hur de genereras, kan något eller allt av ovanstående gälla.