As mentioned, duplicate records are possible due to the structure of the table. Although it *should* be finding that as well.
Personally, I wouldn't bother with the select -> insert / update. I'd simply use an INSERT ON DUPLICATE KEY UPDATE syntax, which will require that the sessionid is specified as a primary key (or at minimum a unique key).
I'd be looking towards the configurations for sessions. The defaults require that cookies be enabled, but its possible that a user does not have cookies enabled and has lost track of their session (transid is also not enabled by default). So I'd also suggest the first thing to look for is verify either:
2. All unique.
If all unique, you're good to go. They may be the same *user* within them, but if the user doesn't provide a method of tracking them using cookies or you providing the sessionid in the querystring through manual placement (only required with header redirects), or through trans sid, than there is no way to track that user.
Sessions do also have ways to manipulate them in an. . . easier(?) fashion. I use (?) there since its more work, but less maintenance to use the session handlers. PHP 5.4 has a class and interface for the SessionHandler[Interface] which can be implemented / overridden, but prior to that you can use individual function registers. These let you intercept the calls to each step in sequence for the session handling. You can choose what to do with them; you can intercept them and store in a single file for all sessions, or in a database, or use a combination of both or whatever you want to do.
BTW, for your purposes it may be simpler to change the save path on the sessions to a local only directory, then iterate the directory and check the filemtime() on each of the session files. If its within the past 10 minutes, increment a counter as "online". This won't let you identify whom the user is (if you have a login system for example), but there are methods to do that as well, albeit taking a lot of work since there are three different serialization methods, and no method to extract them to a datastructure (only to the session superglobal from what I can tell). Somewhere down the line I evaluated the serialized structures and wrote handlers for each of them, but I haven't a clue what I did with that code (I don't typically use the sessionhandlers, but with the 5.4 interfaces I will move towards that with new versions). Fortunately, they can be changed in which case although it takes the most space, the wddx handlers themselves have a method of unserialize and serialize built in.
header('HTTP/1.1 420 Enhance Your Calm');